从Paxos到ZooKeeper(三)ZooKeeper的ZAB协议

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/lwl2014100338/article/details/82825369

ZAB协议

(一)ZAB协议是ZooKeeper实现数据一致性的核心算法
(二)ZAB协议实现了一种主备模式的系统架构保持集群中各副本之间数据的一致性
ZooKeeper使用单一的主进程接收并处理客户端所有事务请求,采用ZAB的原子广播协议,将服务器数据状态变更以事务Proposal的形式广播到所有副本进程
(三)ZAB协议必须可以保证一个全局的变更序列被顺序应用
ZAB协议需要保证如果一个状态变更已经被处理,那么所有其依赖的的状态都应该已被处理
(四)ZAB协议对于那些会改变ZooKeeper服务器数据状态的事物请求的处理方式
如果主进程出现奔溃退出或者重启,ZAB协议需要保证主进程依然正常工作
处理方式:所有事务请求须由一个全局唯一的服务器协调处理,这样的服务器称为Leader服务器,剩余服务器则成为Follower服务器。Leader服务器负责将一个客户端事物请求转换成一个事物Proposal(提议),并将该Proposal分发给集群中所有Follower服务器,之后Leader服务器等待所有Follower服务器反馈,一旦超过半数Follower服务器进行正确的反馈后,那么Leader服务器会向所有的Follower服务器分发Commit消息,要求将前一个Proposal提交

协议介绍

(一)ZAB协议包括了两种基本的模式,分别是奔溃恢复和消息广播。
(二)选举Leader完成退出奔溃恢复模式
(三)当集群中已经有过半的Follower服务器完成和Leader服务器的状态同步,整个服务框架进入消息广播模式
(四)如果已经村子一个Leader服务器负责消息广播,新加入的服务器自觉进入数据恢复模式
(五)当Leader服务器出现异常时,或者集群中不存在过半的服务器与该Leader服务器保持正常通信,在进行新一轮原子广播协议操作之前,所有的进程会首先使用奔溃恢复协议使彼此达到一致状态

消息广播

(一)ZAB协议的二阶段提交移除了中断逻辑,所有Follower服务器要么正常反馈Leader提交的事务Proposal,要么抛弃Leader服务器
(二)这种简化的二阶段提交模型,无法处理Leader富而无奔溃退出而带来的数据不一致问题,所有ZAB协议添加了另一种模式即奔溃恢复解决这个问题
(三)消息广播协议基于FIFO的TCP协议进行网络通信,所以可以很好的保证消息接收和发送的顺序性
(四)Leader服务器会为每一个Follower服务器各自分配一个单独队列,将需要广播的事务依次放入队列中,根据FIFO策略进行消息发送,每一个Follower服务器接收到事务之后,都会首先将其以日志的形式写入本地磁盘中,写入成功后反馈给Leader服务器一个Ack响应

奔溃恢复

(一)Leader服务器出现奔溃或者由于网络原因导致Leader服务器失去了与过半Follower服务器的正常通信,就会进入奔溃恢复模式
(二)为了保证程序正确运行,整个恢复过程需要选举出一个新的Leader服务器,不仅需要让Leader服务器知道自己自身被选为Leader服务器,还需要让集群中其他所有机器可以快速感知到新选举出的Leader服务器,这就需要可靠高效的Leader选举算法

猜你喜欢

转载自blog.csdn.net/lwl2014100338/article/details/82825369