ZooKeeper並沒有完全採用Paxos算法，而是使用了一種稱爲ZooKeeper Atomic Broadcast（ZAB，ZooKeeper原子消息廣播協議）的協議作爲其數據一致性的核心算法。
包括兩種基本的模式，分別是崩潰恢復和消息廣播。
消息廣播
ZAB協議的消息廣播過程使用的是一個原子廣播協議，類似於一個二階段提交過程。ZAB協議的二階段提交過程中，移除了中斷邏輯，所有的Follower服務器要麼正常反饋Leader提出的事務Proposal，要麼就拋棄Leader服務器。我們可以在過半的Follower服務器已經返回Ack之後就開始提交事務Proposal，而不需要等待集羣中所有的Follower服務器都反饋響應。
但此模型下，無法處理Leader服務器崩潰退出而帶來的數據不一致問題。因此在ZAB協議中添加了另一個模式，即採用崩潰恢復模式來解決這個問題。
另外，整個消息廣播協議是基於具有FIFO特性的TCP協議來進行網絡通信的，因此能夠很容易地保證消息廣播過程中消息接收與發送的順序性。Leader服務器會爲每個事物Proposal提前分配一個全局單調遞增的唯一ＩＤ，即事物ＩＤ（ZXID）
崩潰恢復
Leader服務器出現崩潰，或者說由於網絡原因導致Leader服務器失去了與過半Follower的聯繫，那麼就會進入崩潰恢復模式。
Leader選舉算法要保證兩件事：能夠確保提交已經被Leader提交的事務Proposal，同時丟棄已經被跳過的事務Proposal（即丟棄其他服務器未收到的事務）。針對以上要求，如果讓Leader選舉算法能夠保證新選舉出來的Leader服務器擁有集羣中所有機器最高編號（即ZXID最大）的事務Proposal（重點，是所有服務器都有的最高編號），那麼就可以保證這個新選舉出來的Leader一定具有所有已提交的提案。更爲重要的是，如果讓具有最高編號事務Proposal的機器來稱爲Leader，就可以省去Leader服務器檢查Proposal的提交和丟棄工作的這一步操作了。
同步數據
1.提交已經被提交的事務Proposal
Leader服務器會爲每一Follower服務器都準備一個隊列，並將那些沒有被各Follower服務器同步的事務以Proposal消息的形式逐個發送給Follower服務器，並在每一Proposal消息後邊緊接着再發送一個Commit消息，以表示該事務已經被提交。同步完後，Follower服務器才加入到真正的可用Follower列表中。
2.處理被丟棄的事務Proposal
新Leader服務器會根據自己服務器上最後被提交的Proposal來和Follower服務器的Proposal進行對比，比對的結果當然是Leader會要求Follower進行一個回退操作——回退到一個確實已經被集羣中過半機器提交的最新的事務Proposal。
ZXID是一個64位的數字，低32位可以看做是一個簡單的單調遞增的計數器，每個客戶端事務請求加1，高32位則代表了Leader週期epoch的編號，每當選舉產生一個新的Leader服務器，就會從這個Leader服務器上讀取本地日誌中最大事務的ZXID，解析出epoch的值，然後加1，作爲新的epoch，並將低32位置0來開始生成新的ZXID。