持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第26天，点击查看活动详情
zookeeper的ZAB协议简单介绍
zookeeper是采用的原子广播协议来作为其数据一致性的核心算法，ZAB是一种支持崩溃恢复的原子广播协议；
基本描述：
Zab协议定义了一些会改变Zookeeper服务器节点数据状态的事务的请求的处理方式；
zookeeper集群中有一个Lieader服务器，作为所有事务请求的全局处理服务器；
leader服务器会将客户端发来的请求转化成一个Proposal，并将这个Proposal下发给集群中所有的follower节点，并且等待follwer服务器的正确反馈，当超过半数的follower服务器都向leader节点反馈之后，leader就会向所有的follower节点发送事务的commit提交指令，将之前的Proposal进行提交；
ZAB协议包含两种基本模式；
-
崩溃恢复
意思就是说在集群正常运行过程中，leader服务器突然不明情况的在集群中失联了，可能是leader挂掉了也可能是网络断掉了，这种生情况下原本的集群状态就发生了改变，因此zookeeper需要继续保证集群工作而重新选举新的leader出来，快速高效的选举出新的leader并且及时的通知代集群中各个节点；
-
消息广播
Leader服务器会为每个客户端请求的事务对应的Proposal，并且在把Proposal广播到集群中之前，Leader服务器会⾸先为这个事务Proposal分配⼀个全局单调递增的唯⼀ID，称之 为事务ID（ZXID），由于ZAB协议需要保证每个消息严格的因果关系，因此必须将每个事务Proposal按 照其ZXID的先后顺序来进⾏排序和处理。
大概流程是在消息⼴播过程中：
- 首先Leader为每⼀个Follower服务器都各⾃分配⼀个队列
- 然后将需要⼴播的事务 Proposal 按照顺序放⼊这些队列中去
- 根据 FIFO（先进先出）策略进⾏消息发送
- Follower服务器在接收到这个事务Proposal，都会⾸先将其以事务⽇志的形式写⼊到本地磁盘中
- 并且在成功写⼊后反馈给Leader服务器⼀个Ack响应
- 当Leader服务器接收到超过半数Follower的 Ack响应后，就会⼴播⼀个Commit消息给所有的Follower服务器以通知其进⾏事务提交
- 同时Leader ⾃身也会完成对事务的提交，⽽每⼀个Follower服务器在接收到Commit消息后，也会完成对事务的提交；
同步数据：
在集群选出Leader之后，在正式处理接收客户端的事务请求之前， Leader服务器会⾸先确认事务⽇志中的所有Proposal是否都已经被集群中过半的机器提交了，即判断当前集群是否完成数据同步。
在正常的稳定的集群运行中所有正常运⾏的服务器， Follower 并和 Leader 要保持同步。Leader服务器 需要确保所有的Follower服务器能够接收到每⼀条事务Proposal，并且能够正确地将所有已经提交了的 事务Proposal应⽤到内存数据库中去。
Leader服务器会为每⼀个Follower服务器都准备⼀个队 列，并将那些没有被各Follower服务器同步的事务以Proposal消息的形式逐个发送给Follower服务器， 并在每⼀个Proposal消息后⾯紧接着再发送⼀个Commit消息，以表示该事务已经被提交。等到 Follower服务器将所有其尚未同步的事务 Proposal 都从 Leader 服务器上同步过来并成功应⽤到本地数 据库中后，Leader服务器就会将该Follower服务器加⼊到真正的可⽤Follower列表中，并开始之后的其 他流程。
