分布式系统之中心化复制集管理

文章首发于公众号：松花皮蛋的黑板报
作者就职于京东,在稳定性保障、敏捷开发、高级JAVA、微服务架构有深入的理解

为了避免分布式系统单点异常引发的系统可靠性和高可用问题，可行的办法就是数据冗余，也称为复制集，那么复制集是怎么管理的呢？

实际上管理方式可以有去中心化副本集和中心化副本集两种。

去中心化副本集的特点是，无中心节点，所有节点地位平等，都可以接受读写请求，通过协商达到数据的一致。这种方式可用性比较强，只要大多数节点存活就可以对外提供服务，缺点也很明显，它的协议流程复杂。

中心化副本集的特点是，节点之间有主从逻辑关系，主节点负责所有请求的写操作，从节点复制主节点的数据，从节点集的作用是当主节点异常时从中选举出一个新的主节点。这种方式将复杂问题转换成一个有成熟解决方案的问题，将分布式的并发操作转换成单点并发，虽然逻辑变得简单了，但是主节点异常后，即使有主节点切换机制，也会出现短暂的不可用。

目前来看，数据的分布式存储普遍采用中心化副本集管理方式，那么接下来我将介绍这种方式的三个关键点，如下：

(1)、主节点和从节点之间的数据同步如何实现？方式是同步还是异步？
(2)、从节点能否提供数据读取数据，如果允许，如何保证客户端不会读取到重复或者过时的数据？
(3)、主节点的选举机制是怎么样的？

首先来说说主从节点数据更新流程。

如果采用同步的方式进行同步数据的话，意味着对于客户端请求，主节点一直阻塞该请求，直到将数据成功复制到所有的从节点，才能向客户端返回。显然，同步模式下，可靠性非常好，但是更新可用性非常差，只要有一个节点异常，就无法完成更新。而且，响应延迟比较大，取决于副本集中网络延迟最大、处理速度最慢的节点。

如果采用异步的方式进行同步数据的话，它只需要保证客户端写请求在一个节点上完成就立即响应返回，这里说的节点，通常是主节点，不过当写请求完成而复制操作还没开始时主节点异常，这将导致更新失效，关键在于客户端以为已经成功了，它永远不会重试刚刚的写操作。另外，需要注意的是，异步模式下的同步是弱一致性的，客户端有可能读取不到最新的数据。

在数据同步的时候不管选择同步模式和异步模式都有各自的优劣，那么在技术方案评估时，选择哪种方案，取决于系统对一致性、可用性、响应延迟的要求。

在主从节点数据同步的流程中，还有一个关键点需要交待清楚，数据同步路径问题，这样描述可能让人摸不着头脑，你可以理解为数据具体是怎么流动的。通常有两种方式，分别为链式和主从模式。

链式的意思是数据从一个节点推送到相邻最近的节点，最近节点可以用节点间心跳TTL来衡量，TTL表示IP数据包在计算机网络中可以转发的最大跳数。这种方式的数据能够充分利用网络资源，各个节点的压力都非常均衡，但是需要经过多个节点，写入延迟大，所以一般不采用这种方式，更多选用下面要说的主从模式。

主从模式是指数据从主节点同步到从节点，但是这个数据一般是操作事件数据，这样通知到从节点后，从节点会从主节点根据事件描述拉取相应的数据，优点是写入延迟小，缺点是主节点的压力比较大。

前面有说到，在主从节点数据同步流程中，有可能部分节点会写入失败，那这种情况应该怎么处理呢？

分布式存储中的数据复制服务大多数是一种尽力而为的服务模型，不保证一定成功，针对同步失败，依赖于具体系统的处理方案。比如可以约束向客户端返回写入成功的前提条件，包括数据是否写入主节点、数据是否写入一定数量的节点等等，然后采取相应的补偿事务，最终保证数据的一致性。

前面花了很大的篇幅来阐述数据同步问题，接下来谈谈第二个关键点，也就是从节点是否也可以提供读取数据的服务。个人觉得，从节点如果能提供对外服务的话可以很好发挥出数据的局部性，位置相近的请求来源的延迟可以更低，当然可能会出现同步不及时的数据不一致情形，如果系统不太关心及时性的话那就无伤大雅。

最后再来说说主节点选举机制，新的主节点可以是上级指定也可以是民主选举方式选出来的。

键值对存储数据库Redis采取的就是上级指定方式，Redis集群中有一个哨兵节点，它与主从节点保持固定心跳，在超时时间内联系不到主节点，则判定主节点为异常状态，然后将主节点中的一个从节点提升为新的主节点。另外一种民主选举的方式使用的是共识算法，就是多个节点对某个节点是否成为新节点这个事情达到一致的看法，不管是主节点是真的异常，还是网络问题导致误以为主节点异常了。显然，民主选举需要保证在一个选举周期内不会出现多个主节点，比如消息引擎Kafka约定序列号最大的那个才是真正的主节点。

好，今天分享了如何理解分布式系统中的数据复制问题，希望能帮助到你，欢迎分享给你的朋友们。

文章来源：www.liangsonghua.me

作者介绍：京东资深工程师-梁松华，在稳定性保障、敏捷开发、JAVA高级、微服务架构方面有深入的理解