關於一致性協議
說起分佈式一致性協議的始祖，就不得不提到larmport大師發表的< The Part-Time Parliament>論文，但在這個論文中描述的paxos算法很長時間只停留在理論階段，在實際的工程中又出現了很多的變種。Zookeeper的ZAB，Viewstamped Replication（VR），raft，multi-paxos，這些都可以被稱之爲Leader-based一致性協議。不同的是，multi-paxos leader是作爲對經典paxos的優化而提出，通過選擇一個proposer作爲leader降低多個proposer引起衝突的頻率，合併階段一從而將一次決議的平均消息代價縮小到最優的兩次，實際上就算有多個leader存在，算法還是安全的，只是退化爲經典的paxos算法。而經典的paxos，從一個提案被提出到被接受分爲兩個階段，第一個階段去詢問值，第二階段根據詢問的結果提出值。這兩個階段是無法分割的，兩個階段的每個細節都是精心設計的，相互關聯，共同保障了協議的一致性。而VR,ZAB,Raft這些強調合法leader的唯一性協議，它們直接從leader的角度描述協議的流程，也從leader的角度出發論證正確性。但是實際上它們使用了和Paxos完全一樣的原理來保證協議的安全性，當同時存在多個節點同時嘗試成爲leader或者不知一個節點認爲自己時leader時，本質上它們和經典Paxos中多個proposer並存的情形沒什麼不同。
算法描述
和raft一樣，zab中的角色也分別負責三個主要的職能，發起提議的leader，投標表決以及參加競選的follower和沒有任何投票及選舉權的learner。與raft不同的是，zab用的是epoch和count的組合來唯一表示一個entry, 而raft用的是term和index的組合來確定一個entry，其中epoch和count的組合被稱作zxid。
在 ZAB 協議的事務編號 Zxid 設計中，Zxid 是一個 64 位的數字，其中低 32 位是一個簡單的單調遞增的計數器，針對客戶端每一個事務請求，計數器加 1；而高 32 位則代表 Leader 週期 epoch 的編號，每個當選產生一個新的 Leader 服務器，就會從這個 Leader 服務器上取出其本地日誌中最大事務的ZXID，並從中讀取 epoch 值，然後加 1，以此作爲新的 epoch，並將低 32 位從 0 開始計數。
選舉階段
在這個階段，zab協議可配置多種leader election算法，包括basic paxos的選舉算法以及Fast Leader Election。
這個階段結束之後，獲得大多數選票的follower將成爲準leader，這時候它還不是leader不能履行leader的職責，隨後的同步階段過後，他才能真正的履行leader的職責。
發現階段
在這個階段，followers 跟準 leader 進行通信，同步 followers 最近接收的事務提議。這個一階段的主要目的是發現當前大多數節點接收的最新提議，並且準 leader 生成新的 epoch，讓 followers 接受，更新它們的 acceptedEpoch
一個 follower 只會連接一個 leader，如果有一個節點 f 認爲另一個 follower p 是 leader，f 在嘗試連接 p 時會被拒絕，f 被拒絕之後，就會進入 Phase 0。
同步階段
同步階段主要是利用 leader 前一階段獲得的最新提議歷史，同步集羣中所有的副本。只有當 quorum 都同步完成，準 leader 纔會成爲真正的 leader。follower 只會接收 zxid 比自己的 lastZxid 大的提議。
廣播階段
Broadcast模式使用二階段提交，但是簡化了協議，不需要abort。follower要麼ack，要麼拋棄Leader，因爲zookeeper保證了每次只有一個Leader。另外也不需要等待所有Server的ACK，只需要一個quorum應答就可以了。
到了這個階段，Zookeeper 集羣才能正式對外提供事務服務，並且 leader 可以進行消息廣播。同時如果有新的節點加入，還需要對新節點進行同步。
值得注意的是，ZAB 提交事務並不像 2PC 一樣需要全部 follower 都 ACK，只需要得到 quorum （超過半數的節點）的 ACK 就可以了。
回覆階段
在工程實現中通常會把發現階段與同步階段合併成一個恢復階段
一致性保證
- 全局有序：如果消息 a 在消息 b 之前被投遞，那麼在任何一臺服務器，消息 a都會在消息 b 之前被投遞。
- 因果有序：如果消息 a 在消息 b 之前發生（a 導致了 b），並被一起發送，則 a 始終在 b 之前被執行。
VS Raft
raft的基於日誌複製的狀態機，對日誌的要求是連續的，而zab則是由multi paxos延伸出來的，允許有日誌空洞，所以zab對網絡抖動的容忍性更高。
zab選舉leader的過程非常嚴格，開始要經歷準leader階段，同步階段之後才能開始真正的履行leader的職責。而相比於raft，raft的leader選舉則相對寬鬆，所以在leader從宕機到重新加入集羣的過程中，raft的情況要相對複雜得多。
關於心跳，raft只是單向的從leader到follower，在follower超時之後轉變爲candidate發起競選，而zab實現了雙向的數據流動，zab通過leader及follower都可以轉變爲candidate發出競選。
其他
選舉階段中的Fast Leader Election可以參考這篇文章
https://zhuanlan.zhihu.com/p/27335748
參考資料
http://blog.xiaohansong.com/2016/08/25/zab/
https://zhuanlan.zhihu.com/p/25332350
https://feisky.xyz/distributed/zab.html
http://www.cs.cornell.edu/courses/cs6452/2012sp/papers/zab-ieee.pdf