ZAB協議
ZAB協議簡述
ZAB是專門為ZooKeeper設計的崩潰可恢復的原子訊息廣播演算法。基於該協議ZooKeeper實現了一種主備模式的系統架構來保持叢集中各副本之間資料的一致性。具體的：
- 客戶端的事務請求由主程序處理，並以事務的方式，原子的廣播到叢集中。
- ZAB協議保證，叢集中只有一個主程序能夠處理客戶端的請求。
- 為保證事務的順序性，ZAB協議必須能夠保證一個全域性的變更序列被順序應用於事務的提交。
- 在當前主程序奔潰退出或重啟，Zk叢集依舊能夠正常工作。
訊息廣播
ZooKeeper設計成只允許唯一的一個 Leader伺服器來進行事務請求的處理。Leader伺服器在接收到客戶端的事務請求後，會生成對應的事務提案併發起一輪廣播協議（如果叢集中的非Leader伺服器接收到客戶端的事務請求時，則會將這個事務請求轉發給Leader伺服器）。
當過半的 Follower伺服器已經反饋Leader伺服器Ack之後，Leader伺服器就開始向叢集中廣播提交事務的訊息，則收到訊息的伺服器開始在本地執行事務的commit。
在整個訊息廣播過程中，Leader伺服器會為事務 Proposal分配一個全域性單調遞增的唯一ID，稱之為事務ID（即ZXID）。由於ZAB協議需要保證每個訊息嚴格的因果關係，因此必須將每一個事務 Proposal按照其ZXID的先後順序來進行排序與處理。
具體的，在訊息廣播過程中，Leader伺服器會為每一個 Follower伺服器都各自分配一個單獨的佇列，然後將需要廣播的事務 Proposal依次放入這些佇列中去，並且根據FIFO策略進行訊息傳送。每一個 Follower伺服器在接收到這個事務 Proposal之後，都會首先將其以事務日誌的形式寫入到本地磁碟中去，並且在成功寫入後反饋給 Leader伺服器個Ack響應。當 Leader伺服器接收到超過半數 Follower的Ack響應後，就會廣播一個Commit訊息給所有的 Follower伺服器以通知其進行事務提交，同時 Leader自身也會完成對事務的提交，而每一個 Follower伺服器在接收到 Commit訊息後，也會完成對事務的提交。
崩潰恢復
當 Leader伺服器出現崩潰，或者說由於網路原因導致 Leader伺服器失去了與過半 Follower的聯絡，那麼就會進入崩潰恢復模式。
在ZAB協議中，為了保證程式的正確執行，整個恢復過程結束後需要選舉出一個新的 Leader伺服器。因此，ZAB協議需要一個高效且可靠的 Leader選舉演算法。ZAB協議針對奔潰恢復的核心內容：
-
ZAB協議需要確保那些已經在 Leader伺服器上提交的事務最終被所有伺服器都提交；
-
ZAB協議需要確保丟棄那些只在 Leader伺服器上被提出的事務；
-
Leader選舉演算法能夠保證新選舉出來的 Leader伺服器擁有叢集中所有機器最高編號（即ZXID最大）的事務 Proposal，那麼就可以保證這個新選舉出來的 Leader一定具有所有已經提交的提案。
總結上述三個核心思想，來應對可能會出現的問題：
- 當Leader發出提交事務Proposal-1000後掛掉了，那麼該事務要麼被某個Follower執行了，或者所有的Follower都沒有執行。此時開始選舉新的Leader，會判斷ZXID最大的Follower成為Leader，假如該Follower提交了事務Proposal-1000，那麼它會將這條記錄廣播給其他Follower，否則，所有的Follower都沒有提交Proposal-1000。
- 當Leader向Follower提出事務Proposal-1000後掛掉了，然後大半數的Follower迴應Leader資訊ACK，但是因為Leader已經掛掉了，因此所有Follower不會收到Leader的Commit資訊，此時Followers就可以直接拋棄該提議。