前一篇文章說到了 Zookeeper 基本介紹及其工作原理，本文將詳解 Zookeeper 運行中的 ZAB 協議及其選主流程。關注我的公衆號「Java面典」，每天 10：24 和你一起了解更多 Java 相關知識點。
ZAB 協議
事務編號 Zxid（事務請求計數器 + epoch）
在 ZAB ( ZooKeeper Atomic Broadcast , ZooKeeper 原子消息廣播協議） 協議的事務編號 Zxid 設計中，Zxid 是一個 64 位的數字，其中低 32 位是一個簡單的單調遞增的計數器，針對客戶端每一個事務請求，計數器加 1；而高 32 位則代表 Leader 週期 epoch 的編號，每個當選產生一個新的 Leader 服務器，就會從這個 Leader 服務器上取出其本地日誌中最大事務的 Zxid，並從中讀取 epoch 值，然後加 1，以此作爲新的 epoch，並將低 32 位從 0 開始計數。
Zxid（Transaction id）類似於 RDBMS 中的事務 ID，用於標識一次更新操作的 Proposal（提議）
ID。爲了保證順序性，該 Zkid 必須單調遞增。
epoch
epoch：可以理解爲當前集羣所處的年代或者週期，每個 Leader 就像皇帝，都有自己的年號，所以每次改朝換代，Leader 變更之後，都會在前一個年代的基礎上加 1。這樣就算舊的 Leader 崩潰恢復之後，也沒有人聽他的了，因爲 Follower 只聽從當前年代的 Leader 的命令。
Zab 協議有兩種模式-恢復模式（選主）、廣播模式（同步）
Zab 協議有兩種模式，它們分別是恢復模式（選主）和廣播模式（同步）。當服務啓動或者在領導者崩潰後，Zab 就進入了恢復模式，當領導者被選舉出來，且大多數 Server 完成了和 Leader 的狀態同步以後，恢復模式就結束了。狀態同步保證了 Leader 和 Server 具有相同的系統狀態。
ZAB 協議 4 階段
Leader election（選舉階段）
選出準 Leader：節點在一開始都處於選舉階段，只要有一個節點得到超半數節點的票數，它就可以當選準 Leader。只有到達 廣播階段（broadcast） 準 Leader 纔會成爲真正的 Leader。這一階段的目的是就是爲了選出一個準 Leader，然後進入下一個階段。
Discovery（發現階段）
接受提議、生成 epoch、接受 epoch： 在這個階段，Follower 跟準 Leader 進行通信，同步 Follower 最近接收的事務提議。這個一階段的主要目的是發現當前大多數節點接收的最新提議，並且準 Leader 生成新的 epoch，讓 Follower 接受，更新它們的 accepted Epoch， 一個 Follower 只會連接一個 Leader，如果有一個節點 f 認爲另一個 Follower p 是 Leader，f 在嘗試連接 p 時會被拒絕，f 被拒絕之後，就會進入重新選舉階段。
Synchronization（同步階段）
同步 Follower 副本：同步階段主要是利用 Leader 前一階段獲得的最新提議歷史，同步集羣中所有的副本。只有當 大多數節點都同步完成，準 Leader 纔會成爲真正的 Leader。Follower 只會接收 Zxid 比自己的 lastZxid 大的提議。
Broadcast（廣播階段）
Leader 消息廣播:到了這個階段，Zookeeper 集羣才能正式對外提供事務服務，並且 Leader 可以進行消息廣播。同時如果有新的節點加入，還需要對新節點進行同步。ZAB 提交事務並不像 2PC 一樣需要全部 Follower 都 ACK，只需要得到超過半數的節點的 ACK 就可以了。
ZAB 協議 JAVA 實現
FLE-發現階段和同步合併爲 Recovery Phase（恢復階段）
ZAB 協議的 Java 版本實現跟上面的定義有些不同，選舉階段使用的是 Fast Leader Election（FLE），它包含了選舉的發現職責。因爲 FLE 會選舉擁有最新提議歷史的節點作爲 Leader，這樣就省去了發現最新提議的步驟。實際的實現將 發現階段 和 同步合併爲 Recovery Phase（恢復階段）。所以，ZAB 的實現只有三個階段：Fast Leader Election；Recovery Phase；Broadcast Phase。
Leader 選舉流程
每個 Sever 首先給自己投票，然後用自己的選票和其他 Sever 選票對比，權重大的勝出，使用權重較大的更新自身選票箱。具體選舉過程如下：
- 每個 Server 啓動以後都詢問其它的 Server 它要投票給誰。對於其他 Server 的詢問，Server 每次根據自己的狀態都回復自己推薦的 Leader 的 id 和上一次處理事務的 Zxid（系統啓動時每個 Server 都會推薦自己）；
- 收到所有 Server 回覆以後，就計算出 Zxid 最大的那個 Server，並將這個 Server 相關信息設置成下一次要投票的 Server；
- 計算這過程中獲得票數最多的的 Sever 爲獲勝者，如果獲勝者的票數超過半數，則改Server 被選爲 Leader。否則，繼續這個過程，直到 Leader 被選舉出來；
- Leader 就會開始等待 Server 連接；
- Follower 連接 Leader，將最大的 Zxid 發送給 Leader；
- Leader 根據 Follower 的 Zxid 確定同步點，至此選舉階段完成；
- 選舉階段完成 Leader 同步後通知 Follower 已經成爲 uptodate 狀態；
- Follower 收到 uptodate 消息後，又可以重新接受 client 的請求進行服務了。
目前有 5 臺服務器，每臺服務器均沒有數據，它們的編號分別是 1,2,3,4,5 按編號依次啓動，它們的選擇舉過程如下：
- 服務器 1 啓動，給自己投票，然後發投票信息，由於其它機器還沒有啓動所以它收不到反饋信息，服務器 1 的狀態一直屬於 Looking；
- 服務器 2 啓動，給自己投票，同時與之前啓動的服務器 1 交換結果，由於服務器 2 的編號大所以服務器 2 勝出，但此時投票數沒有大於半數，所以兩個服務器的狀態依然是 Looking；
- 服務器 3 啓動，給自己投票，同時與之前啓動的服務器 1,2 交換信息，由於服務器 3 的編號最大所以服務器 3 勝出，此時投票數正好大於半數，所以服務器 3 成爲領導者，服務器1,2 成爲小弟；
- 服務器 4 啓動，給自己投票，同時與之前啓動的服務器 1,2,3 交換信息，儘管服務器 4 的編號大，但之前服務器 3 已經勝出，所以服務器 4 只能成爲小弟；
- 服務器 5 啓動，後面的邏輯同服務器 4 成爲小弟。