ZAB(Zookeeper Atomic Broadcast)算法是Zookeeper爲了實現分佈式協調及數據一致性而設計的算法。相對於Raft算法，ZAB算法除了投票機制，還增加了節點ID和數據ID的比較來優先選主。
此係列文章先來分析ZAB Leader選舉的原理及實現，在後續《分佈式數據複製》的系列文章中，我們再回過頭來實現ZAB算法的分佈式數據複製功能。
Leader選舉：
選舉原則：在同一任職週期內，節點的數據ID越大，表示該節點的數據越新，數據ID最大的節點優先被投票。所有節點的數據ID都相同，則節點ID最大的節點優先被投票。當一個節點的得票數超過節點半數，則該節點成爲主節點。
節點狀態：
-
Looking，選舉狀態，集羣中沒有主節點，該節點進入投票階段。
-
Leading，領導者狀態，當前節點爲主節點，向其他節點發送心跳消息。
-
Following，跟隨者狀態，集羣中已經選出主節點，則該節點轉換成跟隨者狀態，接收主節點發送的心跳消息。
-
Observing，觀察者狀態，沒有投票權和選舉權，接收主節點發送的數據同步消息。
消息類型：
-
Vote，投票消息，包含節點數據ID(zxID)，節點ID(serverID)，選舉週期(epoch)，被選舉節點ID(voteID)。
-
Heartbeat，心跳消息，Follower接收Leader的心跳消息，重置選舉計時器。
選舉過程：
-
節點剛啓動時，默認爲Following狀態。
-
節點啓動後，狀態切換爲Looking狀態，先投票給自己，然後將投票消息發送給其他節點。投票消息：Vote(epoch, zxID, serverID)。
-
節點收到其他節點的投票消息後，比較zxID和serverID選出主節點，將選出主節點的投票消息廣播給其他節點。
-
選出的主節點計算得票數，如果超過集羣中節點半數，則切換爲Leading狀態，並向其他節點發送心跳消息。
-
其他節點切換爲Following狀態。
假設有3個節點，選舉過程如下圖：
-
初始3個節點都是Following狀態，數據ID都爲0。
-
各節點epoch加1，切換爲Looking狀態，然後投票給自己，再把投票消息廣播出去，voteID是自身節點ID。
-
節點收到投票消息後，由於epoch和數據ID都一致，所以將自己的票都投給節點ID最大的節點3，voteID修改爲3，再次將投票消息廣播出去。
-
節點3計算得票數，如果大於節點半數，則切換爲Leading狀態，成爲主節點。向其他節點發送心跳消息，其他節點切換爲Following狀態。
網絡分區：
網絡分區恢復後的處理機制與Raft相似，可以參考Raft算法系列文章來了解。
總結：
ZAB選舉算法，節點有Following、Looking、Leading和Observing 4種狀態；節點數據ID和節點ID最大，且得票數過半才能成爲主節點。因此算法時間相對較長，但是穩定性在三種選主算法中最好。節點故障恢復或者網絡分區恢復後，會觸發選主，但是不一定真正切主，只有符合選主原則的節點才能成爲主節點。
ZAB算法的Leader選舉原理講解完了，下一篇文章《分佈式選舉-ZAB算法-2 Leader選舉 代碼實現》我們來具體看看如何用代碼實現分佈式環境下的ZAB Leader選舉。
獲取Zab算法的實現代碼，請關注公衆號，後臺回覆“ Zab ”獲取源碼。
