深入理解 ZAB：ZooKeeper 原子廣播協議的工作原理

在這里插入圖片描述

- - ZAB 協議：ZooKeeper 如何做到高可用和強一致？🔒
  - ZAB 協議的核心目標 🎯
  - ZAB 協議的關鍵概念 💡
  - ZAB 協議的運行階段 🎬
  - - 階段一：Leader 選舉 (Leader Election) 🗳?
    - 階段二：發現與同步 (Discovery and Synchronization) 📡🤝
    - 階段三：廣播 (Broadcast) 📢?
  - ZAB 協議如何保證一致性？🔒
  - 總結：可靠的分布式協調基石 💎

🌟我的其他文章也講解的比較有趣😁，如果喜歡博主的講解方式，可以多多支持一下，感謝🤗！

其他優質專欄：【🎇SpringBoot】【🎉多線程】【🎨Redis】【?設計模式專欄（已完結）】…等

如果喜歡作者的講解方式，可以點贊收藏加關注，你的支持就是我的動力
?更多文章請看個人主頁：碼熔burning

ZAB 協議：ZooKeeper 如何做到高可用和強一致？🔒

在使用 Apache ZooKeeper 時，我們知道它是一個分布式協調服務，常用于配置管理、命名服務、分布式同步（如分布式鎖）、組服務等。ZooKeeper 能夠提供高可用和一致性的服務，其核心秘訣就在于它內部實現的ZAB (ZooKeeper Atomic Broadcast) 協議。

ZAB 協議是專為 ZooKeeper 設計的一種崩潰可恢復的原子廣播協議。它的主要目標是確保 ZooKeeper 服務的所有副本（稱為 Peer，包括 Leader 和 Follower）之間保持狀態的一致性，并且所有對狀態的更新（事務）都能夠按照全局唯一的順序被處理。

簡單來說，ZAB 協議就是要解決如何在分布式環境中，讓大家（ZooKeeper 的各個節點）對同一個事情（數據更新）達成一致意見，并且這個過程是可靠的，即使有節點崩潰了也能恢復。🤝

ZAB 協議的核心目標 🎯

ZAB 協議主要確保以下兩點：

一致性 (Consistency): 保證所有正確的 ZooKeeper 節點都具有相同的系統狀態副本。無論客戶端連接到哪個節點，都能看到相同的數據。
全局有序性 (Global Ordering): 所有修改 ZooKeeper 狀態的事務都會被賦予一個全局唯一的序列號，并且所有節點都會按照這個序列號的順序來處理這些事務。

ZAB 協議的關鍵概念 💡

理解 ZAB 協議，需要先掌握幾個核心概念：

原子廣播 (Atomic Broadcast): ZAB 協議的核心思想。它保證了任何一個事務（對 ZooKeeper 狀態的修改操作）要么被 ZooKeeper 集群中的所有節點都接受并處理，要么一個節點都不處理。并且，所有節點處理這些事務的順序是完全一致的。想象一下電視直播，所有觀眾看到的畫面內容和順序都是一樣的。📺
角色 (Roles): 在 ZooKeeper 集群中，節點主要有三種角色：
- Leader (領導者): 集群中只有一個 Leader，負責處理所有的寫請求（狀態修改）。它接收客戶端的寫請求，生成新的事務，并將事務廣播給 Follower。📢
- Follower (跟隨者): 負責同步 Leader 發來的事務，并將事務應用到自己的狀態上。它處理客戶端的讀請求。👥
- Observer (觀察者): 與 Follower 類似，也同步 Leader 發來的事務并應用到自己的狀態上。但它不參與 Leader 選舉和寫請求的投票過程。主要用于擴展讀性能。👀
事務 (Transaction): 對 ZooKeeper 狀態的每一次修改操作都抽象為一個事務。例如，創建節點、刪除節點、設置節點數據等都是事務。📝
Zookeeper 事務 ID (ZXID): 每個事務都有一個唯一的 64 位數字標識，稱為 ZXID。ZXID 是單調遞增的，它保證了事務的全局順序性。ZXID 的高 32 位通常代表 Leader 的周期（Epoch），低 32 位代表該 Epoch 內的事務序列號。🔢
周期 (Epoch): Leader 選舉成功后，新的 Leader 會創建一個新的 Epoch。Epoch 是一個單調遞增的數字，用來標識 Leader 的一個任期。每次發生 Leader 切換，Epoch 都會增加。Epoch 的作用是為了區分不同 Leader 任期內產生的事務。🗓?
過半機制 (Quorum): ZAB 協議基于過半機制來實現一致性和可靠性。任何一個寫事務，都需要集群中半數以上的節點（包括 Leader 自己）成功接收并確認，Leader 才會提交這個事務。同樣，Leader 的選舉也需要獲得過半節點的投票。🗳?

ZAB 協議的運行階段 🎬

ZAB 協議的運行主要分為三個階段：

階段一：Leader 選舉 (Leader Election) 🗳?

當 ZooKeeper 集群啟動時，或者當前的 Leader 發生故障、網絡中斷時，集群會進入 Leader 選舉階段。

這個階段的目標是從所有正常運行的節點中選舉出一個新的 Leader。選舉過程可能會比較復雜，但核心是基于某種規則（比如每個節點都會給自己投票，并向其他節點發送自己的投票信息，包括自己認為的 Leader 及其最新的事務 ID ZXID）進行協商，最終得票過半的節點成為新的 Leader。

新的 Leader 誕生后，會生成一個新的 Epoch，這個 Epoch 將作為后續事務 ZXID 的高 32 位。

階段二：發現與同步 (Discovery and Synchronization) 📡🤝

新的 Leader 選舉出來后，它并不知道其他 Follower 節點當前的狀態是什么樣的。有些 Follower 可能丟失了一些最新的事務，有些可能還停留在舊的 Leader 周期。

這個階段的目標是讓新的 Leader 和所有 Follower 達到一致的狀態，特別是保證所有 Follower 都擁有 Leader 提議過的所有事務。

具體過程大致是：

新的 Leader 會與所有 Follower 建立連接。
Follower 會向 Leader 報告自己當前接收到的最新事務的 ZXID。
Leader 會根據 Follower 報告的 ZXID，找出 Follower 缺失的事務。
- 如果 Follower 的 ZXID 落后于 Leader，Leader 會將 Follower 缺失的事務發送給它進行同步。
- 如果 Follower 的 ZXID 甚至超前于 Leader (這在理論上不應該發生，但在某些極端情況下可能存在臟數據)，Leader 會要求 Follower 回滾到 Leader 的最新狀態。
Leader 需要等待過半的 Follower 完成同步，確保大多數節點的狀態與 Leader 一致。

這個階段非常重要，它保證了在開始處理新的寫請求之前，集群中的大多數節點已經處于一個一致的、最新的狀態。

階段三：廣播 (Broadcast) 📢?

一旦過半的 Follower 與 Leader 完成同步，集群就進入了正常運行的廣播階段。

在這個階段，Leader 開始接收客戶端的寫請求。對于每一個寫請求，Leader 會執行以下操作：

生成新的事務： 將客戶端的寫請求轉換為一個內部的事務對象，并分配一個新的、單調遞增的 ZXID（新的 Epoch + 當前 Epoch 內的計數器）。
提議 (Propose)： Leader 將這個新的事務提議給所有的 Follower。
廣播 (Broadcast)： Leader 將事務發送給所有連接的 Follower。
確認 (Acknowledge)： Follower 收到事務提議后，會將其寫入自己的事務日志，并向 Leader 發送一個確認 (ACK)。📝??👍
提交 (Commit)： Leader 收到過半的 Follower 的確認后，認為這個事務已經被大多數節點接受， Leader 就會向所有 Follower 發送一個 Commit 命令。收到 Commit 命令的 Follower 會將事務應用到自己的內存狀態中。Leader 自己也會將事務應用到自己的狀態中。?

整個廣播過程是原子性的： 事務要么在所有節點上都提交，要么都不提交。并且，由于 ZXID 的全局有序性，所有節點都會按照 ZXID 的順序來處理和應用事務，保證了狀態的一致。

ZAB 協議如何保證一致性？🔒

ZAB 協議通過結合上述概念和階段，保證了分布式環境下的數據一致性：

Leader 選舉和 Epoch： 每次 Leader 切換都引入新的 Epoch，保證了不同 Leader 周期產生的事務不會混淆。新的 Leader 會基于大多數節點的狀態來確定從哪里開始新的 Epoch 和 ZXID，避免了腦裂問題導致的不同 Leader 提交沖突的事務。
ZXID 的單調遞增： 為每個事務提供了唯一的全局順序標識，所有節點按序處理，保證了事務應用的順序一致。
過半機制： 任何寫操作的提交都依賴于過半節點的確認。這意味著如果一個事務被提交了，它就肯定存在于集群中至少過半的節點上。當發生故障需要選舉新的 Leader 時，新的 Leader 一定是從擁有最新已提交事務（最高 ZXID）的節點中選出的，從而保證了新的 Leader 的狀態包含了所有已提交的事務。即使舊的 Leader 提議了某個事務但未獲得過半確認就崩潰了，新的 Leader 也不會提交那個未完成的事務。半數以下的節點崩潰不會影響服務的可用性。💪