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 服務實現中很重要的一點：順序性。順序請求，順序響應；主節點事務順序提交，從節點按順序響應事務等等。