文章目錄

• ZAB協議
• • 消息廣播
  • 崩潰恢復

---

ZAB協議

ZAB（ZooKeeper Atomic Broadcast 原子廣播） 協議是為分布式協調服務ZooKeeper專門設計的一種支持崩潰恢復的原子廣播協議。 在ZooKeeper中，主要依賴ZAB協議來實現分布式數據一致性，基于該協議，ZooKeeper實現了一種主備模式的系統架構來保持集群中各個副本之間的數據一致性。

ZAB協議包括了兩種基本的模式，分別是崩潰恢復和消息廣播。

消息廣播

為了保證集群中存在過半的機器能夠和Leader服務器的數據狀態保持一致，ZAB協議中引入了消息廣播模式。

在上面我們提到了，ZooKeeper集群中只有Leader服務器能夠執行寫操作，為了保證集群的數據一致性，我們需要將Leader節點更新的數據同步到Follower與Observer服務器中，所以當Leader服務器接收到客戶端發送的寫請求后，會自動生成對應的提案并發起一輪消息廣播。

消息廣播的執行流程如下：

接受到客戶端發送的事務請求，Leader服務器為其生成對應的事務提議。

Leader為每一個Follower和Observer都準備了一個FIFO的隊列，并把提議發送到隊列上。

當Follower接收到事務提議后，都會先將其以事務日志的形式寫入本地磁盤中，然后再寫入成功后反饋給Leader服務器一個ACK。

當Leader接收到半數以上Follower節點的ACK，它就會認為大部分節點都同意議題，準備開始提交。

Leader向所有節點發送提交事務的Commit請求，完成事務。

消息廣播流程
為了防止因為網絡等原因導致的Follower、Observer節點處理請求的順序不同而導致的數據不一致問題，保證消息廣播過程中消息接收與發送的順序性，消息廣播中引入了**FIFO隊列**和**事務ID**來解決這個問題。

• 在消息廣播的過程中，Leader服務器會為每一個Follower、Observer服務器都各自分配一個單獨的隊列，然后將需要廣播的事務提議放到這些隊列中，并根據FIFO策略進行消息發送。由于ZAB由于協議是通過TCP協議來進行網絡通信的，這樣不僅保證了消息的發送順序性，也保證了接受順序性。
• 在廣播事務提議之前，Leader服務器會先給這個提議分配一個全局單調遞增的唯一事務ID（ZXID）。為了保證每一個消息嚴格的因果關系，必須將每一個事務提議按照其ZXID的先后順序來進行排序與處理。

如果你了解過二階段提交（2PC）協議，你會發現其實消息廣播的過程實際上就是一個簡化版本的二階段提交過程，他將二階段提交中的中斷邏輯刪除，Leader服務器不需要等待集群中的全部Follower服務器都響應反饋，只需要得到過半Follower的ACK就開始執行事務的提交。這種簡化版的2PC雖然提高了效率，但是無法處理Leader服務器崩潰退出而導致的數據不一致問題，因此ZooKeeper中又添加了崩潰恢復模式來解決這個問題。

崩潰恢復

當Leader服務器出現崩潰退出或機器重啟，亦或是集群中不存在半數以上的服務器與Leader服務器保持正常通信時，在重新開始新的一輪原子廣播事務操作之前，此時所有節點都會使用崩潰恢復協議來使彼此達到一個一致的狀態。

崩潰恢復過程需要確保那些已經在Leader服務器上提交的事務最終被所有的事務提交。

假設一個事務中Leader服務器（server2）上被提交了，并且已經得到了過半Follower服務器的ACK反饋，但是在它將Commit消息發送給所有的Follower機器之前，Leader服務器就掛掉了，如下圖：

確保那些已經在Leader服務器上提交的事務最終被所有的事務提交

從上圖可以看到，部分的節點收到了commit請求并進行了提交，而有一部分Leader還沒來得及發送就已經崩潰了。針對這種情況，崩潰恢復必須要確保該事務最終能夠在所有的服務器上都被提交成功，否則將會出現數據不一致的情況。所以在重新選舉的時候，必定會選取ZXID最大的節點來確保其保留了最新的事件。

崩潰恢復過程需要確保丟棄那些只在Leader服務器上被提出的事務。

如果Leader服務器在提交了一個事務之后，還沒來得及廣播發送commit就已經崩潰推出了，從而導致集群中的其他服務器都沒有收到這個事務提議。當原先的Leader節點故障恢復后，再次以Follower的角色加入集群后，此時就因為只有它完成了事務提交，而產生了數據不一致的情況，如下圖：

確保丟棄那些只在Leader服務器上被提出的事務

針對這種情況，我們需要讓server2在故障恢復后能夠丟棄這些只在它這個節點上提出的事務，來確保數據一致。

為了能夠滿足上述的兩個要求，所以ZooKeeper讓Leader選舉算法保證新選舉出來的Leader服務器擁有集群中所有機器最高的事務編號（ZXID最大），那么這就肯定能夠保證新選舉出來的Leader一定具有所有已經提交的提案，此時新的Leader就會將事務日志中尚未提交的消息同步到各個服務器中。

總結

以上是生活随笔為你收集整理的ZooKeeper ZAB协议：崩溃恢复、消息广播的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。