ZAB协议简单剖析

ZAB是为Zookeeper专门设计的一种支持崩溃恢复的消息广播协议，ZAB协议只允许有一个主进程可以响应客户端的事务请求并处理，即Leader。当Leader收到客户端的事务请求之后，它会把请求事务转化为事务proposal，Leader会为每个Follower创建一个队列，将该proposal放入响应队列，保证提案的顺序性。之后会在队列中顺序向其他节点广播该提案，Follower收到后会将其以事务的形式写入到本地日志，并向Leader发送反馈ack。Leader会等待其他Follower的回复，当收到一半以上的Follower响应时，Leader会向其他节点发送commit消息，同时Leadre提交该提案。

ZAB协议有两种模式，分别是故障恢复模式以及消息广播模式。当系统启动或者Leader服务器出现故障时，进入故障恢复模式，讲会开启新的一轮选举。选举产生的Leader会与过半的Follower进行同步，使数据一致。当同步结束之后，进入消息广播模式。

---

故障恢复模式：
在ZAB协议中，每个事务都有一个编号ZXID，ZXID由两部分组成，高32位为选举周期，低32位为递增计数器。

故障恢复模式分为 选举 和 数据同步。
选举：只需要保证选举出来的Leader服务器拥有集群中所有机器的最高编码（ZXID最大），那么就可以保证这个选举出来的Leader具有最新的历史事务集合。
数据同步：Leader会为每一个Follower服务器准备一个队列，将那些没有被各个Follower同步的事务以proposal的形式逐个发送给各个Follower服务器，并在proposal后面紧接着发送一个commit消息，表示该事务已被提交。当Follower将数据同步完成之后，Leader会将其加入到真正可用的Follower列表中。

故障恢复（算法描述）：
选举：
1.每个Follower会将自己最后接受的事务proposal的epoch发送给准Leader。
2.准Leader在收到所有的epoch中选择一个最大值，在此基础上加1形成新的选举周期，发送给所有的Follower。
3.Follower收到后会更新自己的epoch，并反馈给准Leader一个ACK，同时携带历史事务集合。
4.准Leader收到所有的Follower的历史事务集合后，会形成初始化事务集合。
数据同步：
1.Leader将初始化事务集合发送给集群中所有的Follower。
2.Follower收到后对于其中的每一个事务，Follower都会接受，最后将结果反馈给Leader，表示已经接受并处理了初始化事务集合中的事务。
3.Leader收到来自过半的Follower的反馈后，就会向所有的Follower发送commit消息，数据同步完成。

---

选举（底层原理，fastleaderelection算法）
每个节点除了zxid，还由一个myid。成的选票为（myid，zxid）
选举发生在两种情况：启动时选举和运行时选举。

关于选举的概念：
内部投票：其他服务器发来的投票。
外部投票：服务器自身当前的投票。
选举轮次：leader周期，可以理解为epoch。
pk：比较内部投票和外部投票，判断是否变更内部投票。

选举过程：
1.每个节点初始化自己的选票（myid，zxid，当前节点选举轮次，被推举的服务器选举轮次，状态（looking））
2.发送初始化选票
3.接受外部选票
4.判断选举轮次，进行PK
5.变更投票，重新发送
6.归档。每个节点会将收到的所有外部投票进行归档。
7.统计。判断是否由过半的服务器认可当前的内部投票，如果有则终止，选举完成。