分布式一致性协议ZAB(Zookeeper Atomic Broadcast)

什么是ZAB协议

1. ZAB协议全城(Zookeeper Atomic Broadcast),是专门为zookeeper实现分布式协调而设计
2. ZAB协议定义：为分布式协调服务zookeeper专门设计支持原子广播和崩溃恢复协议
3. 基于该协议zookeeper可实现系统架构中各个副本之间的数据一致性。

ZAB协议两种模式：1：消息广播模式

1. 客户端发起写请求。
2. Leader服务端将客户端的请求转化为事务提案，同时为这个提案分配一个全局自增的ZXID
3. Leader与每个Follower之间有一个FIFO的对列，Leader讲消息发送到该队列
4. Follower从队列取出消息处理完[写入本地事务日志]后，往leader队列发送ack确认消息
5. Leader收到半数以上Follower的ack后[2n+1，接收到>=n+1]，认为改提案成功，则执行commit,发送commit消息。

其他注意事项：

• Leader收到的提案，生成ZXID是全局自增的id
• Leader与Follower之间有一个FIFO的消息队列，用于异步解耦

ZAB协议两种模式：2：崩溃恢复

崩溃恢复要求满足如下2个要求：

1. 确保已经被Leader提交的提案proposal必须最终被所有的Follower服务器提交。
2. 确保丢弃已经被Leader提出，但是没有被提交的提案proposal。

能够确保提交已经被 Leader 提交的事务，同时丢弃已经被跳过的事务。

根据上述要求，新选举出来的leader不能包含未提交的proposal，即新选举的leader必须都是已经提交了的proposal的follower服务器节点。同时，新选举的leader节点中含有最高的ZXID。这样做的好处就是可以避免了leader服务器检查proposal的提交和丢弃工作。

leader服务器发生崩溃时分为如下场景：

1. Leader在提出proposal时未提交之前崩溃，则经过崩溃恢复之后，新选举的leader一定不能是刚才的leader。因为这个leader存在未提交的proposal。
2. Leader在发送commit消息之后，崩溃。即消息已经发送到队列中。经过崩溃恢复之后，参与选举的follower服务器(刚才崩溃的leader有可能已经恢复运行，也属于follower节点范畴)中有的节点已经是消费了队列中所有的commit消息。即该follower节点将会被选举为最新的leader。剩下动作就是数据同步过程。

数据同步：
在zookeeper集群中新的leader选举成功之后，
leader会将自身的提交的最大proposal的事物ZXID发送给其他的follower节点。follower节点会根据leader的消息进行回退或者是数据同步操作。最终目的要保证集群中所有节点的数据副本保持一致。

参考

分布式理论(七)—— 一致性协议之 ZAB
ZAB协议