ZAB協定(ZooKeeper Atomic Broadcast)入門

什麼是 ZAB（Zookeeper 原子廣播協定）？

ZAB 協定確定 Zookeeper 複制按順序完成，并且還負責上司節點的選舉和任何失敗節點的恢複

。 在 Zookeeper 生态系統中，leader 節點是一切的核心； 每個叢集都有一個leader節點，其餘的節點是follower。 所有傳入的用戶端請求和狀态更改首先由上司者接收，負責将其複制到所有追随者（及其本身）。 所有傳入的讀取請求也由其自身内的上司者及其追随者進行負載平衡。

ZAB有哪些職責？

順序維護：

如果在 X 的發送者送出事務 Y 之後接收到事務 X，則 Y 必須在 X 之前被排序。如果用戶端在 X 之後發送 Z，那麼 Z 必須在 X 之前被排序。

可靠的傳遞：

如果事務“A”已由一台伺服器送出，那麼所有伺服器都送出它很重要。

總順序維護：

用戶端狀态的更改在 Zookeeper 世界中稱為事務。 如果某個伺服器在事務 Y 之前送出了事務 X，則所有伺服器都必須複制相同的順序。 隻要所需的最小節點數（多數）達到，就會進行交易複制。 在節點發生故障并恢複的情況下，該特定節點應該能夠複制在其停機期間送出的所有事務。

ZAB是如何實施的？

Zookeeper 圍繞兩階段送出協定建構，允許它複制所有事務，同時牢記上述所有設計原則

。上司節點在收到用戶端狀态更改請求後生成交易并為其配置設定序列号。然後它将這些交易發送到所有的跟随者節點并等待他們的确認。

When receiving ACKs from a quorum, commit calls are sent to the quorum

for all the transactions. A follower checks the sequel number of the

issued transaction and only commits it if it doesn’t have any

outstanding transactions in the queue.

當收到來自quorum的 ACK 時，所有事務的送出調用都會發送到quorum。follower檢查發出的事務的序列号，隻有在隊列中沒有任何未完成的事務時才送出它。

一個節點隻有在擁有法定數量的跟随者節點時才能成為上司者節點。如果上司節點出現故障，将調用恢複協定，其中涉及以下階段：

Election of a new leader
Discovery across the cluster.
Synchronization of transactions.
Broadcast of relevant data.
           

下一階段很重要，因為這是所有追随者與新的可能的上司者取得聯系以努力擷取有關最近接受的交易的資訊的時候。這是必要的，因為這是跨叢集的更新事務序列的産生方式。

下一步是同步，基本完成了協定的恢複工作。通過使用由上司者提供的更新資料，叢集中的所有副本都被同步。

上司者将其曆史中存在的交易發送給所有追随者，如果追随者發現他們的曆史落後于上司者，他們就會開始确認傳入的交易。當收到來自仲裁的 ACK 時，将發送送出消息；這是可能的/潛在的上司者實際上成為叢集的新上司者的地方。

參考

Zookeeper Atomic Broadcast Protocol (ZAB) and implementation of Zookeeper. - CloudKarafka, Apache Kafka Message streaming as a Service