ZAB协议：

Zookeeper并没有完全采用Paxos算法，而是使用Zookeeper Atomic Broadcast(ZAB，Zookeeper原子消息广播协议)协议保证数据一致性。ZAB协议并不像Paxos算法那样，是一种通用的分布式一致性算法，而是专门为Zookeeper设计的崩溃可恢复的原子广播消息算法。

其核心是定义了那些会改变Zookeeper数据状态的事务请求处理方式，即：所有的事务都由全局唯一的Leader服务器协调处理，其余的服务器被称为Follower服务器，Leader服务器将客户端的事务请求转化为事务Proposal（提议），并将Proposal提议分发给所有的Follower服务器，然后Leader服务器等待所有Follower服务器的反馈，当“过半”Follower服务器正确的反馈后，Leader服务器会再次向所有Follower分发Commit消息，要求Follower将前一个Proposql进行提交。

消息广播

类似于二阶段提交过程，不同的是移除了中断（脑裂）逻辑，Follower服务器要么正常反馈提交的事务，要么抛弃Leader服务器，这也意味着Leader服务器可以在“过半”的Follower服务器正常ack之后就可以提交Proposal。在消息广播的过程中Leader会给每个Follower。当然这种简化二阶段提交模式下，无法保证Leader服务器崩溃来的数据一致性问题，因此ZAB协议采用另一种模式崩溃恢复模式来解决这个问题

崩溃恢复

Zookeeper中，当Leader服务器出现崩溃或者“过半”的Follower服务器与Leader失去连接时，就会进入崩溃恢复模式，即通过Leader选举算法选出新的Leader服务器，并且让自身和其他Follower服务器感知到新的Leader服务器。ZAP协议设计出的Leader选举算法需要保证两个基本特性：第一、已经在Leader服务器提交过的事务Proposal最终在所有服务器都提交；第二、丢弃那些只是被Leader服务器提出过的事务Proposal。针对这两个基本特性，如果Leader选举算法选出的新Leader服务器拥有集群中ZXID最大的事务，那么新Leader服务器就拥有所有已经提交的事务，这样就可以省去Leader服务器检查Proposal提交和丢弃的操作。

数据同步

新的Leader服务器会为每一个Follower服务器准备一个队列，并将那些没有被各Follower服务器提交的事务的Proposal逐个发送给各Follower服务器，Leader服务器等待正确的提议反馈，随后发出Commit请求，等到各个服务器都将事务同步到本地数据库中，Leader服务器将Follower服务器加入到可用的服务器列表中。

ZXID：低32位代表事务编号，Leader服务器每新产生一个事务会单调递增1；高32位代表Leader周期epoch编号，随每次新一轮的Leader选举会将服务器中拥有最大ZXID的事务Proposal的ZXID高32位单调递增1，即代表Leader周期的变化策略

之前的Leader服务器恢复之后，根据ZXID的递增策略，自己最大的ZXID必定比Quorum集合中更新的epoch的事务Proposal的ZXID要小。所有会以Follower的角色加入集群，和Leader连接后，当前Leader的最新事务Proposal会和Follower服务器上的事务Proposal进行对比，Leader会要求Follower进行回退操作到过半服务器已经提交的事务Proposal

======================================

下一章深入理解ZAB协议