ZAB协议
ZAB集群如何从故障中恢复
如果我们想把ZAB集群恢复到正常状态，那么新领导者就必须确立自己的领导关系，成为唯一有效的领导者，然后作为主节点"领导"各备份节点一起处理读写请求
如何确立领导关系
前面提到，选举出的领导者是在成员发现阶段确立领导关系的。领导者在当选后会递增自己的任期编号，并基于任期编号值的大小来与跟随者协商，最终建立领导关系。具体来说，跟随者会选择任期编号值最大的节点来作为自己的领导者，而被大多数节点认同的领导者将成为真正的领导者。
举个例子。
下面用一个例子来帮助更好地理解。
假设一个ZooKeeper集群由节点A、B、C组成。其中，领导者A已经宕机，节点C是新选出来的领导者，节点B是新的跟随者(为了方便演示，假设节点B、C已提交提案的事务标识符的最大值分别是<1,10>和<1,11>，其中1是任期编号，10、11是事务标识符中的计数器值，节点A宕机前的任期编号也是1)，如图所示。那么节点B、C如何协商建立领导关系呢？
- 首先，节点B、C会把自己的ZAB状态设置为成员发现(DISCOVERY)，这就表明，选举(ELECTION)阶段结束了，进入了下一个阶段，如图所示。
这里补充一下，ZAB协议定义了4种状态来标识节点的运行状态。
1.ELECTION(选举)状态:表明节点在进行领导者选举
2.DISCOVERY(成员发现)状态:表明节点在协商沟通领导者的合法性
3.SYNCHRONIZATION(数据同步)状态:表明集群的各节点以领导者的数据为准，修复数据副本的一致性
4.BROADCAST(广播)状态:表明集群各节点在正常处理写请求。
关于这4种状态，简单了解即可。强调一点，只有当集群大多数节点处于广播状态的时候，集群才能提交提案。
- 接下来，节点B会主动向节点C发送包含自己接收到的领导者任期编号的最大值(也就是前领导者A的任期编号，1)的FOLLOWINFO消息，如图所示。
节点C在接收到来自节点B的信息后，会将包含自己的事务标识符的最大值的LEADINFO消息发送给跟随者。需要注意的是，领导者进入成员发现阶段后会对任期编号加1，即创建新的任期编号，然后基于新任期编号创建新的事务标识符(也就是<2,0>)，如图所示。
当接收到领导者的响应后，跟随者会判断领导者的任期编号是否最新，如果不是，就发起新的选举；如果是，则返回ACKEPOCH消息给领导者。在这里，
节点C的任期编号(也就是2)大于节点B接收到的其他领导任期编号(也就是旧领导者A的任期编号，1)，所以节点B返回确认响应给节点C,并设置ZAB状态为数据同步状态，如图所示
- 最后，领导者在接收到来自大多数节点的ACKEPOCH消息时，会设置ZAB状态为数据同步。在这里，节点C接收到了节点B和节点C自己发送的消息，满足大多数节点的要求，所以，在接收到来自B的消息后，C设置ZAB状态为数据同步状态。如图所示
现在，ZAB协议在成员发现阶段确立了领导者的领导关系，这样领导者就可以行使领导职能了。下一步，ZAB协议要解决的就是数据冲突问题，以实现各节点数据的一致性，那么它是怎么做的呢？
如何处理冲突数据
当进入数据同步状态后，领导者会根据跟随者的事务标识符的最大值，判断以哪种方式处理不一致数据(有DIFF、TRUNC、SNAP3种方式)。
因为节点C已提交提案的事务标识符的最大值(也就是<1,11>)大于节点B已提交提案的事务标识符的最大值(也就是<1,10>),所以节点C会用DIFF的方式修复数据副本的不一致。并返回差异数据(也就是事务标识符为<1,11>的提案)和NEWLEADER消息给节点B,如图所示.
这里强调一点:节点B已提交提案的最大值，也是节点B最新提案的最大值。因为在ZooKeeper实现种，节点退出跟随者状态时(也就是在进入选举前)，所有未提交的提案都会被提交。这是ZooKeeper的设计。
然后，节点B修复不一致数据，返回NEWLEADER消息的确认响应给领导者(即节点C),如图所示.
接着，节点C在接收到来自大多数节点的NEWLEADER消息的确认响应后会将ZAB状态设置为广播状态。在这里，节点C接收到节点B和节点C自己的确认响应，满足大多数确认的要求。所以，在接收到来自节点B的确认响应后，节点C会将自己的ZAB状态设置为广播状态，并发送UPTODATE消息给所有跟随者，通知它们数据同步已经完成了，如图所示。
最后当节点B接收到UPTODATE消息时，它就直到数据同步已经完成，并设置ZAB状态为广播状态，如图所示
注意
在ZooKeeper的代码实现中，处于提交状态的提案是可能会改变的，为什么呢？
-
在ZooKeeper中，一个提案进入提交状态的方式有两种:被复制到大多数节点上和被领导者提交或接收到来自领导者的提交消息(leader.COMMIT)而被提交。
在这种状态下，提交的提案是不会改变的。
-
另外，在ZooKeeper的设计中，节点在退出跟随者状态时(在follower.shutdown()函数中)会将所有本地未提交的提案都提交。需要注意的是，此时提交的提案可能并未被复制到大多数节点上，而且这种设计会导致ZooKeeper中出现处于"提交"状态的提案可能会被删除(也就是接收到领导者的TRUNC消息而删除的提案)的情况。
-
更准确地说，在ZooKeeper中，被复制到大多数节点上地提案最终会被提交，并不会再改变，而只在少数节点存在地提案可能会被提交和不再改变，，也可能会被删除。为了更好地理解，举个具体的例子。
-
如果写请求对应的提案"SET X=1"已经复制到大多数节点上，那么它最终会被提交，之后也不会再改变。也就是说，再没有新的X赋值操作的前提下，不管节点怎么崩溃、领导者如何变更，你查询到的X的值都为1。
-
如果写请求对应的提案"SET X=1"未被复制到大多数节点上，比如在领导者广播消息过程中，领导者崩溃了，那么提案"SET X=1"可能会被复制到大多数节点上提交并不再改变，也可能会被删除。这个行为是未确定的，具体取决于新的领导者是否包含该提案。
-
另外，补充下，在ZAB协议选举出了新的领导者后，该领导者不能立即处理写请求，还需要通过成员发现、数据同步两个阶段进行故障恢复。这是由于ZAB协议的设计决定的，不是所有的共识算法都必须这样，比如通过Raft算法选举出新的领导者后，领导者是可以立即处理写请求的。