分布式算法-Zab

ZAB协议

模式：消息广播、崩溃恢复

消息广播

1. 客户端发起一个写操作请求
2. Leader服务器将客户端的请求转化为事务Proposal提案，同时为每个Proposal分配一个全局ID，zxid
3. Leader服务器为每个Follower服务器分配一个单独的队列，将需要广播的Proposal依次放入到队列中去，根据FIFO策略进行消息发送
4. Follower接收到Proposal后，首先将其以事务日志的方式写入本地磁盘，写入成功后向Leader反馈一个ACK响应消息
5. Leader接收到超过半数以上Follower的ACK响应消息后，认为消息发送成功，可以发送commit消息
6. Leader向所有Follower广播commit消息，自身也会完成事务提交。Follower接收到commit消息后，会将上一条事务提交
7. zk采用zab协议为核心，只要有一台服务器提交了Proposal，确保所有的服务器最终都能正确提交Proposal

该事务提交请求过程类似于两阶段提交过程

广播事务阶段和广播提交阶段

数据不一致情况

1. Leader发起一个事务Proposal后宕机，Follower没有Porposal

2. Leader收到半数ACK宕机，没来的急向Follower发送Commit

崩溃恢复（Leader选举、数据恢复）

zab协议崩溃恢复要求满足两个要求

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

崩溃恢复Leader选举

选举出来的Leader需要满足

1. 新选举出来的Leader不能包含未提交的Proposal。
2. 新选举出来的Leader节点中含有最大的zxid。

zab数据同步

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