1、ZAB 協議介紹
ZAB 協議全稱：Zookeeper Atomic Broadcast（Zookeeper 原子廣播協議）。ZAB協議是為分散式協調服務Zookeeper專門設計的一種支援崩潰恢復和原子廣播的協議。所有客戶端寫入資料都是寫入到 主程式（稱為 Leader）中，然後，由 Leader 複製到備份程式（稱為 Follower）中，從而保證資料一致性。ZAB 只需要 Follower 有一半以上返回 Ack 資訊就可以執行提交，大大減小了同步阻塞，也提高了可用性。當 Leader 服務可以正常使用，就進入訊息廣播模式，當 Leader 不可用時，則進入崩潰恢復模式。
2、訊息廣播
ZAB 協議的訊息廣播過程使用的是一個原子廣播協議，對於客戶端傳送的寫請求，全部由 Leader 接收，Leader 將請求封裝成一個事務，將其傳送給所有 Follwer ，然後，根據所有 Follwer 的反饋，如果超過半數成功響應，則執行 commit 操作。
3、崩潰恢復
當 Leader 崩潰，即Leader 失去與過半 Follwer 的聯絡。可能會出現兩種情況
Leader 在複製資料給所有 Follwer 之後崩潰，怎麼辦？
Leader 在收到 Ack 並提交了自己，同時傳送了部分 commit 出去之後崩潰怎麼辦？
ZAB 定義了 2 個原則：能夠確保提交已經被 Leader 提交的事務，同時丟棄已經被跳過的事務。
Leader 選舉演算法能夠保證新選舉出來的 Leader 伺服器擁有叢集總所有機器編號（即 ZXID 最大）的事務，那麼就能夠保證這個新選舉出來的 Leader 一定具有所有已經提交的提案。
4、資料同步
當崩潰恢復之後，需要在正式工作之前（接收客戶端請求），Leader 伺服器首先確認事務是否都已經被過半的 Follwer 提交了，即是否完成了資料同步。目的是為了保持資料一致。
當所有的 Follwer 伺服器都成功同步之後，Leader 會將這些伺服器加入到可用伺服器列表中。
在 ZAB 協議的事務編號 ZXID 設計中，ZXID 是一個 64 位的數字，其中低 32 位可以看作是一個簡單的遞增的計數器，針對客戶端的每一個事務請求，Leader 都會產生一個新的事務 Proposal 並對該計數器進行 + 1 操作。
而高 32 位則代表了 Leader 伺服器上取出本地日誌中最大事務 Proposal 的 ZXID，並從該 ZXID 中解析出對應的 epoch 值，然後再對這個值加一。
當 Follower 連結上 Leader 之後，Leader 伺服器會根據自己伺服器上最後被提交的 ZXID 和 Follower 上的 ZXID 進行比對，比對結果要麼回滾，要麼和 Leader 同步。