Zab 協議：zookeeper 基於 Paxos 協議的改進協議 zookeeper atomic broadcast 原子廣播協議。
zookeeper 基於 Zab 協議實現選主及事務提交。
一、為什麼需要選主？
選主是複雜分散式服務的一個特有機制，旨在保障系統資料的一致性。
分散式服務一般對於資料的儲存形式是：每個節點都儲存全量資料，每個節點都可以對外提供“一致”的服務，這就涉及到不同節點間的資料同步。
我們所說的可能的資料不一致主要是由資料變更過程引發，因為它涉及服務內所有節點的資料更新。對於 zookeeper， 選主便是保障服務內資料變更觸發，控制及變更後服務各節點資料的一致性的一個重要環節。
二、怎麼選主？
zookeeper 叢集內節點通常處於以下幾種狀態：
1、LEADING：
也就是我們所說的領導者所處的狀態，領導者負責處理接收到的資料變更請求及將變更同步到各個從節點。此處需要注意的是，即使變更資料請求傳送到了從節點，從節點也會將其轉發到主節點。
2、FOLLOWING：
通常情況下從節點所處的狀態，從節點主要負責讀請求處理及參與叢集投票，選舉。
3、LOOKING：
是一種選主過程中的特有狀態，當前服務無主節點時，則所有節點切換為 LOOKING 狀態，遵循 Zab 協議，相互通訊以選舉出主節點。過程完成，則轉換到相應的 LEADING 或者 FOLLOWING 狀態。
選主過程發生在服務初始啟動及執行過程中主節點故障兩種情景下。在正式介紹選主過程之前，先就幾個涉及到的名詞作簡要概述：
1、法定數量：
設定的為了確定協議一致性結果，必須有多少參與方意見達成一致。主要用於確認服務可用或失敗、確認資料更新事務成功等。
2、領導者選舉通知：
選主過程中，各節點間進行通訊的訊息。主要包括兩部分，一個是節點自身的標識sid，會隨著每次重啟自增；另一個是 zookeeper 事務id，簡稱 zxid，標識對 zookeeper 的操作指令順序、大小（遵循 happend before 原則）。
選主過程：
1、服務內的每個節點向其它節點發出自己的投票資訊（sid，zxid），如下圖：
Node1 接收到 Node2 傳送的選舉資訊，會對比自己的投票資訊，當 （zxid1 > zxid2 || zxid1 == zxid2 && sid1 > sid2） 則保持自己的資訊 sid 及 zxid 不變，否則的話則將自身的 sid 及 zxid 更新為 Node2 的 sid 和 zxid。
2、當服務內某個節點獲得了超過法定人數的投票，則選主結束。
主節點進入 LEADING 狀態，其它節點進入 FOLLOWING 狀態，同時開始發起資料同步（從節點在同步資料前無法對外提供服務）。
三、關於事務提交
Zab 協議包含兩種模式：恢復模式及廣播模式。
前面我們提到過恢復模式下的應用，服務初始及主節點故障情況下的領導者選舉，恢復模式結束於領導者被選出及超過法定數量的從節點資料達到同步。
主節點負責處理寫請求及傳送廣播訊息，且需要說明的是，廣播模式下只有主節點可以傳送廣播訊息，如果某個從節點需要傳送廣播資訊，也需要通過主節點進行。
主節點基於Zab協議協商完成寫變更事務提交：
1、主節點廣播傳送事務提交提議
2、從節點接收到提議後，回覆確認資訊通知主節點
3、主節點接收到超過法定數量從節點確認資訊後，廣播傳送事務提交命令到從節點
zookeeper 服務實現中很重要的一點：順序性。順序請求，順序響應；主節點事務順序提交，從節點按順序響應事務等等。