什麼是 ZAB 協議？
ZAB（ZooKeeper Atomic Broadcast）原子廣播協議：
ZAB 協議是爲分佈式協調服務 ZooKeeper 專門設計的一種支持崩潰恢復的原子廣播協議。 在 ZooKeeper 中，主要依賴 ZAB 協議來實現分佈式數據一致性，基於該協議，ZooKeeper 實現了一種主備模式的系統架構來保持集羣中各個副本之間的數據一致性。
在主備模式（Master-Slave 模型），一個主節點和多個備份節點，所有副本的數據都以主節點爲準，主節點採用二階段提交，向備份節點同步數據，如果主節點發生故障，數據最完備的節點將當選主節點。
ZAB 協議兩種基本的模式：
- 崩潰恢復
- 消息廣播
當整個服務框架在啓動過程中，或是當 Leader 服務器出現網絡中斷、崩潰退出與重啓等異常情況時，ZAB 協議就會進人恢復模式並選舉產生新的 Leader 服務器。當選舉產生了新的 Leader 服務器，同時集羣中已經有過半的機器與該 Leader 服務器完成了狀態同步之後，ZAB 協議就會退出恢復模式。其中，所謂的狀態同步是指數據同步，用來保證集羣中存在過半的機器能夠和 Leader 服務器的數據狀態保持一致。
當集羣中已經有過半的 Follower 服務器完成了和 Leader 服務器的狀態同步，那麼整個服務框架就可以進人消息廣播模式了。 當一臺同樣遵守 ZAB 協議的服務器啓動後加人到集羣中時，如果此時集羣中已經存在一個 Leader 服務器在負責進行消息廣播，那麼新加人的服務器就會自覺地進人數據恢復模式：找到 Leader 所在的服務器，並與其進行數據同步，然後一起參與到消息廣播流程中去。
崩潰恢復
服務器啓動時期的 Leader 選舉：
1、每個服務器會發出一個投票，第一次都是投自己，投票信息：（myid，zxid）。
2、處理投票結果並重新投票，處理邏輯：優先選擇 zxid 大的（說明該服務器有最新的數據），然後比較 myid。
3、統計投票，只要超過半數的機器接收到同樣的投票信息，就可以確定 Leader 服務器。
4、改變服務器狀態。
服務器運行時期的 Leader 選舉：
1、變更狀態。Leader 掛後，餘下的非 Observer 服務器都會講自己的服務器狀態變更爲 LOOKING，然後開始進入 Leader 選舉過程。
2、每個 Server 會發出一個投票。在運行期間，每個服務器上的 zxid 可能不同，此時假定 Server1 的 zxid 爲123，Server3 的 zxid 爲122；在第一輪投票中，Server1 和 Server3 都會投自己，產生投票(1, 123)，(3, 122)，然後各自將投票發送給集羣中所有機器。
3、接收來自各個服務器的投票。與啓動時過程相同。
4、處理投票。與啓動時過程相同，此時，Server1將會成爲 Leader。
5、統計投票。與啓動時過程相同。
6、改變服務器的狀態。與啓動時過程相同。
消息廣播
1、事務請求由 Leader 服務器來協調處理，Leader 服務器負責將一個客戶端事務請求轉換成一個事務 Proposal，並將該 Proposal 分發給集羣中所有的 Follower 服務器。事務請求會被賦予一個全局唯一的 64 位自增 id（zxid）,通過 zxid 大小可以實現事務請求有序性。
2、當 Follower 服務器接收到 Proposal ，先將 Proposal 寫到硬盤，寫成功後向 Leader 服務器返回一個 ACK。
3、如果超過半數的 Follower 服務器進行了正確 ACK 後，Leader 服務器再次向所有 Follower 服務器分發 Commit 消息，要求其將前一個 Proposal 進行提交（自己會在本地先執行）。
ZAB 和 Paxos
Zab 是 Paxos 的一種特殊實現嗎？
不，Zab 與 Paxos 是不同的協議。
二者有相同的地方：
- 都有一個 Leader，用來協調 N 個 Follower 的運行。
- Leader 要等待超半數的 Follower 做出正確反饋之後才進行提案。
- 二者都有一個值來代表 Leader 的週期。ZAB 協議中，每個 Proposal 中都包含一個 epoch 值來代表當前的Leader 週期，Paxos 中名字爲 Ballot 。
不同的地方在於：
ZAB 用來構建高可用的分佈式數據主備系統（Zookeeper），Paxos 是用來構建分佈式一致性狀態機系統。
主備份和狀態機複製之間有什麼區別？
狀態機是處理一系列請求的軟件組件。對於每個已處理的請求，它可以修改其內部狀態併產生答覆。狀態機在某種意義上是確定性的，即在給定兩次運行時，如果它接收到相同的請求序列，則它始終會進行相同的內部狀態轉換併產生相同的答覆。
狀態機複製系統是確保所有狀態機副本執行相同順序的客戶端請求的客戶端服務器系統，即使這些請求由客戶端同時提交併由副本以不同順序接收。副本使用諸如Paxos之類的共識算法就客戶端請求的執行順序達成共識。同時發送並在時間上重疊的客戶端請求可以按任何順序執行。如果領導者失敗，則執行恢復的新領導者可以隨意重新排序任何未提交的請求，因爲該請求尚未完成。
對於諸如 Zookeeper 之類的主備份系統，副本在增量（增量）狀態更新的應用程序順序上達成一致，增量更新由主副本生成併發送給其跟隨者。與客戶端請求不同，狀態更新必須從主數據庫的原始初始狀態開始，按照主數據庫的原始原始生成順序進行應用。如果主服務器發生故障，則執行恢復的新主服務器無法任意重新排序未提交的狀態更新，也不能從其他初始狀態開始應用它們。
總之，與對客戶端請求的協議（對於狀態機複製系統）相比，對狀態更新的協議（對於主備份系統）需要更嚴格的順序保證。
ZAB 和 Raft
Zookeeper 的開發始於 2007年，而 Raft 算法的第一稿於2013年發佈。就是說，Zookeeper 的 Zab 算法實際上與Raft 非常相似。它不像 Raft 那樣簡單，但是它已經可以很好地工作，並且有自己的正確性證明。
簡單而言，他們的算法都都是先通過 Leader 選舉，選出一個 Leader，然後 Leader 接受到客戶端的提議時，都是先寫入操作日誌，然後再與其他 Followers 同步日誌，Leader 再 commit 提議，再與其他 Followers 同步提議。如果 Leader 故障，重新走一遍選舉流程，選取最新的操作日誌，然後同步日誌，接着繼續接受客戶端請求等等。過程都是一樣，只不過兩個的實現方式不同，描述方式不同。實現 Raft 的核心是 Term，Zab 的核心是 Zxid。