ZAB協議

（一）ZAB協議是ZooKeeper實現資料一致性的核心演算法
（二）ZAB協議實現了一種主備模式的系統架構保持叢集中各副本之間資料的一致性
ZooKeeper使用單一的主程序接收並處理客戶端所有事務請求，採用ZAB的原子廣播協議，將伺服器資料狀態變更以事務Proposal的形式廣播到所有副本程序
（三）ZAB協議必須可以保證一個全域性的變更序列被順序應用
ZAB協議需要保證如果一個狀態變更已經被處理，那麼所有其依賴的的狀態都應該已被處理
（四）ZAB協議對於那些會改變ZooKeeper伺服器資料狀態的事物請求的處理方式
如果主程序出現奔潰退出或者重啟，ZAB協議需要保證主程序依然正常工作
處理方式：所有事務請求須由一個全域性唯一的伺服器協調處理，這樣的伺服器稱為Leader伺服器，剩餘伺服器則成為Follower伺服器。Leader伺服器負責將一個客戶端事物請求轉換成一個事物Proposal（提議），並將該Proposal分發給叢集中所有Follower伺服器，之後Leader伺服器等待所有Follower伺服器反饋，一旦超過半數Follower伺服器進行正確的反饋後，那麼Leader伺服器會向所有的Follower伺服器分發Commit訊息，要求將前一個Proposal提交

協議介紹

（一）ZAB協議包括了兩種基本的模式，分別是奔潰恢復和訊息廣播。
（二）選舉Leader完成退出奔潰恢復模式
（三）當叢集中已經有過半的Follower伺服器完成和Leader伺服器的狀態同步，整個服務框架進入訊息廣播模式
（四）如果已經村子一個Leader伺服器負責訊息廣播，新加入的伺服器自覺進入資料恢復模式
（五）當Leader伺服器出現異常時，或者叢集中不存在過半的伺服器與該Leader伺服器保持正常通訊，在進行新一輪原子廣播協議操作之前，所有的程序會首先使用奔潰恢復協議使彼此達到一致狀態

訊息廣播

（一）ZAB協議的二階段提交移除了中斷邏輯，所有Follower伺服器要麼正常反饋Leader提交的事務Proposal，要麼拋棄Leader伺服器
（二）這種簡化的二階段提交模型，無法處理Leader富而無奔潰退出而帶來的資料不一致問題，所有ZAB協議添加了另一種模式即奔潰恢復解決這個問題
（三）訊息廣播協議基於FIFO的TCP協議進行網路通訊，所以可以很好的保證訊息接收和傳送的順序性
（四）Leader伺服器會為每一個Follower伺服器各自分配一個單獨佇列，將需要廣播的事務依次放入佇列中，根據FIFO策略進行訊息傳送，每一個Follower伺服器接收到事務之後，都會首先將其以日誌的形式寫入本地磁碟中，寫入成功後反饋給Leader伺服器一個Ack響應

奔潰恢復

（一）Leader伺服器出現奔潰或者由於網路原因導致Leader伺服器失去了與過半Follower伺服器的正常通訊，就會進入奔潰恢復模式
（二）為了保證程式正確執行，整個恢復過程需要選舉出一個新的Leader伺服器，不僅需要讓Leader伺服器知道自己自身被選為Leader伺服器，還需要讓叢集中其他所有機器可以快速感知到新選舉出的Leader伺服器，這就需要可靠高效的Leader選舉演算法