1. ZAB協議
ZAB協議是爲分佈式協調服務ZooKeeper專門設計的一種支持崩潰恢復的原子廣播協議。ZAB協議並不像Paxos算法那樣，是一種通用的分佈式一致性算法，他是一種專門爲ZooKeeper設計的崩潰可恢復的原子消息廣播算法。
在ZooKeeper中，主要依賴於ZAB協議來實現分佈式一致性，基於該協議，ZooKeeper 實現了一種主備模式的系統架構來保持集羣中各副本之間數據的一致性。具體的，ZooKeeper使用一個單一的主進程來接收並處理客戶端的所有事務請求，並採用ZAB的原子廣播協議，將服務器數據的狀態變更以事務Proposal（提案）的形式廣播到所有的副本進程上去。ZAB協議的這個主備架構模型保證了同一時刻集羣中只能夠有一個主進程來廣播服務器的狀態變更。
ZooKeeper協議的核心是定義了那些會改變ZooKeeper服務器狀態的事務請求的處理方式，即：所有事務請求必須由一個全局唯一的服務器來協調處理，這樣的服務器被稱爲Leader服務器，而其他的服務器則稱爲Follower服務器。Leader 服務器負責將一個客戶端事務請求轉換成一個事務Proposal（提議），並將該Proposal 分發給集羣中所有的Follower服務器。之後Leader服務器需要等待所有的Follower服務器的反饋，一旦超過半數的服務器進行了正確的反饋後，那麼Leader服務器就會再次向Follower服務器分發Commit消息，要求將前一個Proposal（提議）進行提交。
1.1 ZAB具體內容
ZAB協議包含兩種模式：崩潰恢復、消息廣播。當整個服務框架在啓動過程中，或Leader服務器發生網絡中斷、崩潰退出、重啓等異常情況時，ZAB協議就會進入恢復模式並選舉產生新的Leader服務器。當選舉產生了新的Leader服務器，同時集羣中有過半的機器與Leader服務器完成了狀態同步之後，ZAB協議就退出崩潰恢復模式，進入消息廣播模式。當一臺同樣遵守ZAB協議的服務器加入到集羣中後，如果此時集羣中已經存在一個Leader服務器在負責進行消息廣播，那麼新加入的服務器就會自覺進入數據恢復模式：找到Leader服務器，與Leader服務器進行數據同步，然後一起參與到消息廣播流程中去。
當Leader服務器不可用或集羣中已經不存在半數以上的Follower服務器與Leader服務器保持正常通信時，那麼在重新開始新一輪的原子廣播事務操作之前，所有進程首先會使用崩潰恢復協議來使彼此達到一個一致的狀態，ZAB流程就會從消息廣播模式進入到崩潰恢復模式。
一個機器要成爲新的Leader，必須獲得過半Follower的支持。
1.2 消息廣播
ZAB協議的消息廣播使用的是一個原子廣播協議，類似於一個二階段提交協議（2PC）過程，針對客戶端的事務請求，Leader服務器會爲其生成對應的事務Proposal（提議），並將其發送給集羣中其餘所有的機器，然後再分別收集各自的選票，最後進行事務提交或回滾。
1.3 崩潰恢復
ZAB協議的消息廣播過程，在正常情況下運行非常良好，但是一旦Leader服務器出現崩潰，或者說由於網絡原因導致Leader服務器失去了與過半Follower的聯繫，那麼就會進入崩潰恢復模式。在這個過程中，ZAB提供了一個高效且可靠的Leader選舉算法。Leader算法不僅僅需要讓Leader知道自己已經被選舉爲Leader，還要讓其他機器也能夠快速的感知到選舉產生的新的Leader服務器。
2. 選舉機制
- 半數機制：集羣中半數以上（不包括一半）機器存活，集羣可用。所以ZooKeeper集羣適合安裝奇數臺服務器。
- ZooKeeper 雖然在配置文件中並沒有指定Master和Slaver。但是在ZooKeeper集羣工作時，會有一個節點被選舉爲Leader，其他爲Follower，Leader是通過內部的選舉機制臨時產生的。
2.1 ZooKeeper的選舉機制
後續補。。。。。。。。。。。。。。。。。