通用组件之Zookeeper-ZAB协议

1） 什么是ZAB协议？

ZAB协议是为ZooKeeper专门设计的一种支持崩溃恢复的原子广播协议。Zookeeper是通过ZAB协议来保证分布式事务的最终一致性的。

2） 须知：

zookeeper的集群模型：
    zookeeper实现了主备模型，即Leader，Follower模型。

3） ZAB协议工作模式-消息广播

1 消息广播模式：

Zookeeper集群必须选举出一个Leader进程用来维护一个Follower可用的客户端列表。将来这些Follower节点可以和客户端进行通信。

​

2 读请求请求细节：

Zookeeper客户端会随机的链接到集群中的一个节点，如果是读请求，就直接从当前节点中读取数据。

 

 

3 写请求请求细节：

1) 写请求被转发到leader上。

2) Leader接收并处理客户端的事务请求将服务器数据的状态变更以事务proposal的形式广播到所有的Follower。

3) 分发之后Leader服务器需要等待所有Follower服务器反馈（ACK）。

4) 超过半数的Follower服务器进行了正确的反馈后，Leader 就会再次向所有的Follower服务器发送Commit消息，要求提交上一个事务proposal并进行本地Commit。

4） ZAB协议工作模式-崩溃恢复

1 崩溃恢复模式
    当Leader服务器出现网络中弄断、崩溃退出或重启等异常时，ZAB协议就会进入崩溃恢复模式，选举产生新Leader。当完成leader选举和数据恢复后，
ZAB协议就会退出崩溃恢复模式，进入消息广播模式。崩溃恢复主要包括两部分：数据恢复和Leader选举。
​

2 数据恢复
    ZAB协议崩溃恢复要求满足以下两个要求：
    1）确保已经被Leader提交的Proposal必须最终被所有的Follower服务器提交。
    2）确保丢弃已经被Leader提出的但是没有被提交的Proposal。
    针对以上要求，我们做出如下分析：
    1）新的Leader不能包含未提交的Proposal。即新的Leader所有的Proposal的都是已提交的Proposal。
    2）新选举的Leader节点中含有最大的zxid。这样可以避免Leader服务器检查Proposal的提交和丢弃工作。
    

补充知识：
    顺序机制：
    每一个proposal按照其zxid的先后顺序进行排序和处理，也就是说当处理某个proposal成功时，他前面的proposal必定全部处理成功了。
    由于ZAB协议需要保证每一个消息的严格的顺序关系，因此必须将每一个proposal按照其zxid的先后顺序进行排序和处理，Leader接收并处理客户端的事务
请求将服务器数据的状态变更以事务proposal（提议）的形式的过程中，首先为这个事务Proposal分配一个全局单递增的唯一ID，称之为事务ID（即zxid），
zxid是64位，高32位是epoch编号，每经过 一次 Leader 选举产生一个新的leader，新的 leader 会将 epoch 号+1，低 32 位是消息计数器，每接收到一条消息
这个值+1，新leader选举后这个值重置为0.
    

2.1同步已提交
    1）完成Leader选举后（新的Leader具有最高的zxid），在正式开始工作之前，Leader服务器会首先确认事务日志中的所有的Proposal是否已经被集群中过
半的服务器 Commit。
    2）Leader服务器需要确保所有的Follower服务器能够接收到每一条事务的Proposal，并且能将所有已经提交的事务Proposal应用到内存数据中。等到Follower
将所有尚未同步的事务Proposal都从Leader服务器上同步完成并且应用到内存数据中以后，Leader才会把该Follower加入到真正可用的Follower列表中。
​

2.2丢弃未提交
    当一个包含了上一个Leader周期中尚未提交的Proposal 的服务器启动时，当这台机器加入集群中，以Follower角色连上Leade 服务器后，Leader服务器会根据
自己服务器上最后提交的Proposal来和Follower服务器的Proposal进行比对，比对的结果肯定是Leader要求Follower进行一个回退操作，回退到一个确实已经被集群
中过半机器Commit的最新 Proposal。
    

3 Leader选举（FLE算法）