ZooKeeper的ZAB协议原理

如果有些概念不清楚，可以先看：ZooKeeper的基本概念

一致性协议有很多种，比如 Paxos、Raft、2PC等，ZooKeeper使用的是ZAB协议。

ZAB（Zookeeper Atomic Broadcast）是为ZooKeeper设计的崩溃恢复原子广播协议，也称为zk原子广播协议。它保证ZooKeeper集群数据的一致性和命令的全局有序性。

ZAB包含两种模式：消息广播、崩溃恢复。

当集群启动时，或Leader服务器异常，或没有过半Follower与Leader正常通信，ZAB协议就会进入崩溃恢复模式，选举产生新的Leader。
当选举产生了新的Leader，同时集群中有过半的Follower与该Leader服务器完成了状态同步（即数据同步）之后，ZAB协议就会退出崩溃恢复模式，进入消息广播模式。
这时，如果有一台遵守ZAB协议的服务器加入集群，因为此时集群中已经存在一个Leader服务器在广播消息，那么该新加入的服务器自动进入恢复模式：找到Leader服务器，并且完成数据同步。同步完成后，作为新的Follower一起参与到消息广播流程中。

读请求：直接由当前节点直接响应。
写请求：若当前节点不是Leader就转发给Leader执行。Leader在收到客户端请求之后，会将这个请求封装成一个事务，并给这个事务分配一个全局递增的唯一事务ID（ZXID），为保证事务的顺序，将每个事务按ZXID进行排序后处理。然后Leader将封装好的事务以广播形式提议到Follower节点。当集群中有过半的Follower服务器进行正确的ACK反馈，Leader就会先commit事务消息，然后发送commit给所有Learner。这个过程可以简称为2pc事务提交。

崩溃恢复有两个阶段：Leader选举、初始化同步。

通过选举算法能够保证新选举出来的Leader服务器拥有集群所有机器编号（即 ZXID 最大）的事务，那么就能够保证这个新选举出来的Leader一定具有所有已经提交的提案。

当选举结束后，会产生一个准Leader，准Leader经过初始化同步后才能变为真正的 Leader。

当崩溃恢复之后，需要在正式工作之前（接收客户端请求），Leader服务器首先确认事务是否都已经被过半的Follwer提交了，即是否完成了数据同步。目的是为了保持数据一致。

当所有的Follwer服务器都成功同步之后，Leader会将这些服务器加入到可用服务器列表中。

同步过程：

为了保证Leader向Learner发送提案的有序，Leader会为每一个Learner服务器准备一个队列；
Leader将那些没有被各个Learner同步的事务封装为Proposal；
Leader将这些Proposal逐条发给各个Learner，并在每一个Proposal后都紧跟一个commit消息，表示该事务已经被提交，Learner可以直接接收并执行；
Learner接收来自于Leader的Proposal，并将其更新到本地；
当Learner更新成功后，会向准Leader发送ACK信息；
Leader服务器在收到来自Learner的ACK后就会将该Learner加入到真正可用的Follower列表或Observer列表。没有反馈ACK，或反馈了但Leader没有收到的Learner，Leader不会将其加入到相应列表。