ZAB一致性協議
ZAB ( ZooKeeper Atomic Broadcast , ZooKeeper 原子消息廣播協議）是zookeeper數據一致性的核心算法。
ZAB協議論文地址：http://www.tcs.hut.fi/Studies/T-79.5001/reports/2012-deSouzaMedeiros.pdf
ZAB 協議並不像 Paxos 算法那樣，是一種通用的分布式一致性算法，它是一種特別為 ZooKeeper 設計的崩潰可恢復的原子消息廣播算法。基於該協議，Zookeeper 實現了一種 主備模式的系統架構來保持集群中各個副本之間數據一致性。
系統架構看看下面這張圖：
上圖顯示了 Zookeeper 如何處理集群中的數據。所有客戶端寫入數據都是寫入到 主進程（ Leader主節點）中，然后由 Leader 復制到備份進程（稱為 Follower）中。從而保證數據一致性。從設計上看，和 Raft 類似。在集群數據同步的過程中，如果出現 Follower 節點崩潰或者 Leader 進程崩潰時，都會通過 Zab 協議來保證數據一致性。
崩潰恢復
消息廣播通過 Quorum 機制，解決了 Follower 節點宕機的情況，但是如果在廣播過程中 Leader 節點崩潰呢？
這就需要 Zab 協議支持的崩潰恢復，崩潰恢復可以保證在 Leader 進程崩潰的時候可以重新選出 Leader，並且保證數據的完整性。
崩潰恢復和集群啟動時的選舉過程是一致的，也就是說，下面的幾種情況都會進入崩潰恢復階段：
初始化集群，剛剛啟動的時候
Leader 崩潰，因為故障宕機
Leader 失去了半數的機器支持，與集群中超過一半的節點斷連
崩潰恢復模式將會開啟新的一輪選舉，選舉產生的 Leader 會與過半的 Follower 進行同步，使數據一致，當與過半的機器同步完成后，就退出恢復模式， 然后進入消息廣播模式。
Zab 中的節點有三種狀態，伴隨着的 Zab 不同階段的轉換，節點狀態也在變化：
Zab協議原理
Zab協議要求每個Leader 都要經歷以下三個階段：
1）發現：要求zookeeper集群必須選舉出一個 Leader 進程，同時 Leader 會維護一個 Follower 可用客戶端列表。將來客戶端可以和這些 Follower節點進行通信。
2）同步：Leader 要負責將本身的數據與 Follower 完成同步，做到多副本存儲。這樣也是提現了CAP中的高可用和分區容錯。Follower將隊列中未處理完的請求消費完成后，寫入本地事務日志中。
3）廣播：Leader 可以接受客戶端新的事務Proposal請求，將新的Proposal請求廣播給所有的 Follower。
選舉算法
當集群新建，或者主機死機，或者主機與一半或以上的從機失去聯系后，都會觸發選擇新的主機操作。有兩種算法fast paxos和basic paxos。
這里fast是主動推送出，只要結果有更新，就馬上同步給其他節點。其他節點可能還沒把自己的票通知給所有節點，就發現自己投的票優先級低，要更新投票，然后更新再重新通知給所有節點。
basic則要每一節點都詢問完，才能知道新結果，然后再去問其他節點新的選舉結果。
fast比basic快的地方，是一個節點，不用和每個節點都交換投票信息后，才能知道自己的票是否要更新。會減少交互次數。
Zab與Paxos算法的聯系與區別
zookeeper采用FastLeaderElection 選舉算法，是標准的 Fast Paxos 算法實現，可解決 LeaderElection選舉算法收斂速度慢的問題。
Paxos 的思想在很多分布式組件中都可以看到，Zab 協議可以認為是基於 Paxos 算法實現的，先來看下兩者之間的聯系：
都存在一個 Leader 進程的角色，負責協調多個 Follower 進程的運行。
都應用 Quorum 機制，Leader 進程都會等待超過半數的 Follower 做出正確的反饋后，才會將一個提案進行提交。
在 Zab 協議中，Zxid 中通過 epoch 來代表當前 Leader 周期，在 Paxos 算法中，同樣存在這樣一個標識，叫做 Ballot Number。
兩者之間的區別是，Paxos 是理論，Zab 是實踐，Paxos 是論文性質的，目的是設計一種通用的分布式一致性算法，而 Zab 協議應用在 ZooKeeper 中，是一個特別設計的崩潰可恢復的原子消息廣播算法。
Zab 協議增加了崩潰恢復的功能，當 Leader 服務器不可用，或者已經半數以上節點失去聯系時，ZooKeeper 會進入恢復模式選舉新的 Leader 服務器，使集群達到一個一致的狀態。