为了避免分布式系统单点异常引发的系统可靠性和高可用问题,可行的办法就是数据冗余,也称为复制集,那么复制集是怎么管理的呢?
实际上管理方式可以有去中心化副本集和中心化副本集两种。
去中心化副本集的特点是,无中心节点,所有节点地位平等,都可以接受读写请求,通过协商达到数据的一致。这种方式可用性比较强,只要大多数节点存活就可以对外提供服务,缺点也很明显,它的协议流程复杂。
中心化副本集的特点是,节点之间有主从逻辑关系,主节点负责所有请求的写操作,从节点复制主节点的数据,从节点集的作用是当主节点异常时从中选举出一个新的主节点。这种方式将复杂问题转换成一个有成熟解决方案的问题,将分布式的并发操作转换成单点并发,虽然逻辑变得简单了,但是主节点异常后,即使有主节点切换机制,也会出现短暂的不可用。
目前来看,数据的分布式存储普遍采用中心化副本集管理方式,那么接下来我将介绍这种方式的三个关键点,如下:
(1)、主节点和从节点之间的数据同步如何实现?方式是同步还是异步?
(2)、从节点能否提供数据读取数据,如果允许,如何保证客户端不会读取到重复或者过时的数据?
(3)、主节点的选举机制是怎么样的?
首先来说说主从节点数据更新流程。
如果采用同步的方式进行同步数据的话,意味着对于客户端请求,主节点一直阻塞该请求,直到将数据成功复制到所有的从节点,才能向客户端返回。显然,同步模式下,可靠性非常好,但是更新可用性非常差,只要有一个节点异常,就无法完成更新。而且,响应延迟比较大,取决于副本集中网络延迟最大、处理速度最慢的节点。
如果采用异步的方式进行同步数据的话,它只需要保证客户端写请求在一个节点上完成就立即响应返回,这里说的节点,通常是主节点,不过当写请求完成而复制操作还没开始时主节点异常,这将导致更新失效,关键在于客户端以为已经成功了,它永远不会重试刚刚的写操作。另外,需要注意的是,异步模式下的同步是弱一致性的,客户端有可能读取不到最新的数据。
在数据同步的时候不管选择同步模式和异步模式都有各自的优劣,那么在技术方案评估时,选择哪种方案,取决于系统对一致性、可用性、响应延迟的要求。
在主从节点数据同步的流程中,还有一个关键点需要交待清楚,数据同步路径问题,这样描述可能让人摸不着头脑,你可以理解为数据具体是怎么流动的。通常有两种方式,分别为链式和主从模式。
链式的意思是数据从一个节点推送到相邻最近的节点,最近节点可以用节点间心跳TTL来衡量,TTL表示IP数据包在计算机网络中可以转发的最大跳数。这种方式的数据能够充分利用网络资源,各个节点的压力都非常均衡,但是需要经过多个节点,写入延迟大,所以一般不采用这种方式,更多选用下面要说的主从模式。
主从模式是指数据从主节点同步到从节点,但是这个数据一般是操作事件数据,这样通知到从节点后,从节点会从主节点根据事件描述拉取相应的数据,优点是写入延迟小,缺点是主节点的压力比较大。
前面有说到,在主从节点数据同步流程中,有可能部分节点会写入失败,那这种情况应该怎么处理呢?
分布式存储中的数据复制服务大多数是一种尽力而为的服务模型,不保证一定成功,针对同步失败,依赖于具体系统的处理方案。比如可以约束向客户端返回写入成功的前提条件,包括数据是否写入主节点、数据是否写入一定数量的节点等等,然后采取相应的补偿事务,最终保证数据的一致性。
前面花了很大的篇幅来阐述数据同步问题,接下来谈谈第二个关键点,也就是从节点是否也可以提供读取数据的服务。个人觉得,从节点如果能提供对外服务的话可以很好发挥出数据的局部性,位置相近的请求来源的延迟可以更低,当然可能会出现同步不及时的数据不一致情形,如果系统不太关心及时性的话那就无伤大雅。
最后再来说说主节点选举机制,新的主节点可以是上级指定也可以是民主选举方式选出来的。
键值对存储数据库Redis采取的就是上级指定方式,Redis集群中有一个哨兵节点,它与主从节点保持固定心跳,在超时时间内联系不到主节点,则判定主节点为异常状态,然后将主节点中的一个从节点提升为新的主节点。另外一种民主选举的方式使用的是共识算法,就是多个节点对某个节点是否成为新节点这个事情达到一致的看法,不管是主节点是真的异常,还是网络问题导致误以为主节点异常了。显然,民主选举需要保证在一个选举周期内不会出现多个主节点,比如消息引擎Kafka约定序列号最大的那个才是真正的主节点。
好,今天分享了如何理解分布式系统中的数据复制问题,希望能帮助到你,欢迎分享给你的朋友们。
网站声明:如果转载,请联系本站管理员。否则一切后果自行承担。
添加我为好友,拉您入交流群!
请使用微信扫一扫!