ZooKeeper一致性協議ZAB學習筆記

一、ZAB 協議介紹

ZAB 協議全稱：Zookeeper Atomic Broadcast（Zookeeper 原子廣播協議）。ZAB協議是爲分佈式協調服務Zookeeper專門設計的一種支持崩潰恢復和原子廣播的協議。全部客戶端寫入數據都是寫入到 主進程（稱爲 Leader）中，而後，由 Leader 複製到備份進程（稱爲 Follower）中，從而保證數據一致性。ZAB 只須要 Follower 有一半以上返回 Ack 信息就能夠執行提交，大大減少了同步阻塞，也提升了可用性。當 Leader 服務能夠正常使用，就進入消息廣播模式，當 Leader 不可用時，則進入崩潰恢復模式。

二、消息廣播

ZAB 協議的消息廣播過程使用的是一個原子廣播協議，對於客戶端發送的寫請求，所有由 Leader 接收，Leader 將請求封裝成一個事務，將其發送給全部 Follwer ，而後，根據全部 Follwer 的反饋，若是超過半數成功響應，則執行 commit 操做。

三、崩潰恢復

當 Leader 崩潰，即Leader 失去與過半 Follwer 的聯繫。可能會出現兩種狀況

Leader 在複製數據給全部 Follwer 以後崩潰，怎麼辦？

Leader 在收到 Ack 並提交了本身，同時發送了部分 commit 出去以後崩潰怎麼辦？

ZAB 定義了 2 個原則：可以確保提交已經被 Leader 提交的事務，同時丟棄已經被跳過的事務。

Leader 選舉算法可以保證新選舉出來的 Leader 服務器擁有集羣總全部機器編號（即 ZXID 最大）的事務，那麼就可以保證這個新選舉出來的 Leader 必定具備全部已經提交的提案。

四、數據同步

當崩潰恢復以後，須要在正式工做以前（接收客戶端請求），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 同步。