ZAB ( ZooKeeper Atomic Broadcast , ZooKeeper 原子消息廣播協議）是zookeeper數據一致性的核心算法。
ZAB 協議並不像 Paxos 算法那樣，是一種通用的分布式一致性算法，它是一種特別為 ZooKeeper 設計的崩潰可恢復的原子消息廣播算法。
ZAB協議主要實現了：
1.使用一個單一的主進程來接收並處理客戶端的所有事務請求，並采用 ZAB 的原子廣播協議，將服務器數據的狀態變更以事務 Proposal 的形式廣播到所有的副本進程上去。
2.保證一個全局的變更序列被順序應用。
ZooKeeper是一個樹形結構，很多操作都要先檢查才能確定能不能執行，比如P1的事務t1可能是創建節點“/a”，t2可能是創建節點“/a/aa”，只有先創建了父節點“/a”，才能創建子節點“/a/aa”。為了保證這一點，ZAB要保證同一個leader的發起的事務要按順序被apply，同時還要保證只有先前的leader的所有事務都被apply之后，新選的leader才能在發起事務。
3.當前主進程出現異常情況的時候，依舊能夠正常工作。
ZAB 協議的核心：定義了事務請求的處理方式。
所有事務請求必須由一個全局唯一的服務器來協調處理，這樣的服務器被稱為 Leader服務器，而余下的其他服務器則成為 Follower 服務器。 Leader 服務器負責將一個客戶端事務請求轉換成一個事務proposal（提議），並將該 Proposal分發給集群中所有的Follower服務器。之后 Leader 服務器需要等待所有Follower 服務器的反饋,一旦超過半數的Follower服務器進行了正確的反饋后，那么 Leader 就會再次向所有的 Follower服務器分發Commit消息，要求其將前一個proposal進行提交。
這種事務處理方式與2PC（兩階段提交協議）區別在於，兩階段提交協議的第二階段中，需要等到所有參與者的"YES"回復才會提交事務，只要有一個參與者反饋為"NO"或者超時無反饋，都需要中斷和回滾事務。
ZAB協議介紹：
ZAB 協議包括兩種基本的模式，分別是崩潰恢復和消息廣播。
當整個服務框架在啟動過程中，或是當 Leader 服務器出現網絡中斷、崩潰退出與重啟等異常情況時， ZAB 協議就會進入恢復模式並選舉產生新的 Leader 服務器。當選舉產生了新的Leader 服務器同時集群中已經有過半的機器與該 Leader 服務器完成了狀態同步之后，ZAB 協議就會退出恢復模式。
當集群中已經有過半的 Follower 服務器完成了和 Leader 服務器的狀態同步，那么整個服務框架就可以進入消息廣播模式了。當一台同樣遵守 ZAB 協議的服務器啟動后加入到集群中時，如果此時集群中已經存在一個 Leader 服務器在負責進行消息廣播 ， 那么新加人的服務器就會自覺地進人數據恢復模式：找到 Leader 所在的服務器，並與其進行數據同步，然后一起參與到消息廣播流程中去。
下面重點講解崩潰回復和消息廣播的過程。
消息廣播
ZAB 協議的消息廣播過程使用的是一個原子廣播協議，類似於一個二階段提交過程。針對客戶端的事務請求， Leader 服務器會為其生成對應的事務 Proposal ,並將其發送給集群中其余所有的機器，然后再分別收集各自的選票，最后進行事務提交。
在 ZAB 協議的二階段提交過程中，移除了中斷邏輯，所有的 Follower 服務器要么正常反饋 Leader 提出的事務 Proposal ,要么就拋棄Leader 服務器。同時， ZAB 協議將二階段提交中的中斷邏輯移除意味着我們可以在過半的 Follower 服務器已經反饋 Ack 之后就開始提交事務 Proposal 了，而不需要等待集群中所有的 Follower 服務器都反饋響應。這種簡化了的二階段提交模型無法處理 Leader 服務器崩潰退出而帶來的數據不一致問題，此時采用崩潰恢復模式來解決這個問題。
在整個消息廣播過程中， Leader 服務器會為每個事務請求生成對應的 Proposal來進行廣播，並且在廣播事務 Proposal 之前， Leader 服務器會首先為這個事務 Proposal 分配一個全局單調遞增的唯一事務ID (即 ZXID )。
Leader 服務器會為每一個 Follower 服務器都各自分配一個單獨的隊列，然后將需要廣播的事務 Proposal 依次放入這些隊列中去，並且根據 FIFO策略進行消息發送。每一個 Follower 服務器在接收到這個事務 Proposal 之后，都會首先將其以事務日志的形式寫入到本地磁盤中去，並且在成功寫入后反饋給 Leader 服務器一個 Ack 響應。當 Leader 服務器接收到超過半數 Follower 的 Ack 響應后，就會廣播一個Commit 消息給所有的 Follower 服務器以通知其進行事務提交，同時 Leader 自身也會完成對事務的提交。
崩潰恢復
Leader 服務器出現崩潰，或者說由於網絡原因導致 Leader 服務器失去了與過半 Follower 的聯系，那么就會進入崩潰恢復模式。Leader 選舉算法不僅僅需要讓 Leader自己知道其自身已經被選舉為 Leader ,同時還需要讓集群中的所有其他機器也能夠快速地感知到選舉產生的新的 Leader 服務器。
ZAB 協議規定了如果一個事務 Proposal 在一台機器上被處理成功，那么應該在所有的機器上都被處理成功，哪怕機器出現故障崩潰。
下面介紹兩種崩潰恢復中的場景和zab協議需要保證的特性：
1.ZAB 協議需要確保那些已經在 Leader 服務器上提交的事務最終被所有服務器都提交
假設一個事務在 Leader 服務器上被提交了，並且已經得到過半 Follower 服務器的Ack 反饋，但是在它將 Commit 消息發送給所有 Follower 機器之前， Leader 服務器掛了，針對這種情況， ZAB 協議就需要確保該事務最終能夠在所有的服務器上都被提交成功，否則將出現不一致。
2.ZAB協議需要確保丟棄那些只在 Leader 服務器上被提出的事務
假設初始的 Leader 服務器 在提出了一個事務之后就崩潰退出了，導致集群中的其他服務器都沒有收到這個事務，當該服務器恢復過來再次加入到集群中的時候 ，ZAB協議需要確保丟棄這個事務。
針對以上兩點需求，zab協議需要設計的選舉算法應該滿足：確保提交已經被 Leader 提交的事務 Proposal，同時丟棄已經被跳過的事務 Proposal 。
如果讓 Leader 選舉算法能夠保證新選舉出來的 Leader 服務器擁有集群中所有機器最高編號（即 ZXID 最大）的事務 Proposal,那么就可以保證這個新選舉出來的 Leader —定具有所有已經提交的提案。同時，如果讓具有最高編號事務 Proposal 的機器來成為 Leader, 就可以省去 Leader 服務器檢查 Proposal 的提交和丟棄工作的這一步操作。
數據同步
Leader 服務器會為每一個 Follower 服務器都准備一個隊列，並將那些沒有被各 Follower 服務器同步的事務以 Proposal 消息的形式逐個發送給 Follower 服務器，並在每一個 Proposal 消息后面緊接着再發送一個 Commit 消息，以表示該事務已經被提交。等到 Follower 服務器將所有其尚未同步的事務 Proposal 都從 Leader 服務器上同步過來並成功應用到本地數據庫中后， Leader 服務器就會將該 Follower 服務器加入到真正的可用 Follower 列表中，並開始之后的其他流程。
下面來看 ZAB 協議是如何處理那些需要被丟棄的事務 Proposal 的。在 ZAB 協議的事務編號 ZXID 設計中， ZXID 是一個 64 位的數字，低 32 位可以看作是一個簡單的單調遞增的計數器，針對客戶端的每一個事務請求， Leader 服務器在產生一個新的事務 Proposal 的時候，都會對該計數器進行加1操作；高 32 位代表了 Leader 周期 epoch 的編號，每當選舉產生一個新的 Leader 服務器，就會從這個 Leader 服務器上取出其本地日志中最大事務 Proposal 的 ZXID ,並從該 ZXID 中解析出對應的 epoch 值，然后再對其進行加1操作，之后就會以此編號作為新的 epoch, 並將低 32 位置0來開始生成新的 ZXID 。
基於這樣的策略，當一個包含了上一個 Leader 周期中尚未提交過的事務 Proposal的服務器啟動加入到集群中，發現此時集群中已經存在leader，將自身以Follower 角色連接上 Leader 服務器之后， Leader 服務器會根據自己服務器上最后被提交的 Proposal來和 Follower 服務器的 Proposal進行比對，發現follower中有上一個leader周期的事務Proposal時，Leader 會要求 Follower 進行一個回退操作——回退到一個確實已經被集群中過半機器提交的最新的事務 Proposal 。