理解Zookeeper的Leader選舉過程

選擇機制中的概念

serverId（服務器ID 既 myid）

• 比如有三臺服務器，編號分別是1,2,3。

• 編號越大在選擇算法中的權重越大。

zxid（最新的事物ID 既 LastLoggedZxid）

• 服務器中存放的最大數據ID。

• ID值越大說明數據越新，在選舉算法中數據越新權重越大。

epoch （邏輯時鐘 既 PeerEpoch）

• 每個服務器都會給自己投票，或者叫投票次數，同一輪投票過程中的邏輯時鐘值是相同的。

• 每投完一次票這個數據就會增加，然後與接收到的其它服務器返回的投票信息中的數值相比。

• 如果收到低於當前輪次的投票結果，該投票無效，需更新到當前輪次和當前的投票結果。

選舉狀態

• LOOKING，競選狀態。

• FOLLOWING，隨從狀態，同步leader狀態，參與投票。

• OBSERVING，觀察狀態,同步leader狀態，不參與投票。

• LEADING，領導者狀態。

選舉算法

通過 zoo.cfg 配置文件中的 electionAlg 屬性指定 （1-3），要理解算法,需要一些paxos算法的理論基礎。

• 1 對應：LeaderElection 算法。

• 2 對應：AuthFastLeaderElection 算法。

• 3 對應：FastLeaderElection 默認的算法。

投票內容

• 選舉人ID

• 選舉人數據ID

• 選舉人選舉輪數

• 選舉人選舉狀態

• 推舉人ID

• 推舉人選舉輪數

Leader選舉

Leader選舉有如下兩種

• 第一種：服務器初始化啓動的Leader選舉。

• 第二種：服務器運行時期的Leader選舉（服務器運行期間無法和Leader保持連接）。

Leader選舉的前提條件

• 只有服務器狀態在LOOKING（競選狀態）狀態纔會去執行選舉算法。

• Zookeeper 的集羣規模至少是2臺機器，纔可以選舉Leader，這裏以3臺機器集羣爲例。

• 當一臺服務器啓動是不能選舉的，等第二臺服務器啓動後，兩臺機器之間可以互相通信，纔可以進行Leader選舉

• 服務器運行期間無法和Leader保持連接的時候。

服務器啓動時期的 Leader 選舉

在集羣初始化階段，當有一臺服務器Server1啓動時，其單獨無法進行和完成Leader選舉，當第二臺服務器Server2啓動後，此時兩臺機器可以相互通信，每臺機器都試圖找到Leader，於是進入Leader選舉過程。選舉過程如下：

(1) 每個Server發出一個投票投給自己。由於是初始情況，Server1和Server2都會將自己作爲Leader服務器來進行投票，每次投票會包含所推舉的服務器的myid和ZXID，使用(myid, ZXID)來表示，此時Server1的投票爲(1, 0)，Server2的投票爲(2, 0)，然後各自將這個投票發給集羣中其他機器。

(2) 接受來自各個服務器的投票。集羣的每個服務器收到投票後，首先判斷該投票的有效性，如檢查是否是本輪投票、是否來自LOOKING狀態的服務器。

(3) 處理投票。針對每一個投票，服務器都需要將別人的投票和自己的投票進行PK，PK規則如下

1、優先檢查ZXID。ZXID比較大的服務器優先作爲Leader。

2、如果ZXID相同，那麼就比較myid。myid較大的服務器作爲Leader服務器。

對於Server1而言，它的投票是(1, 0)，接收Server2的投票爲(2, 0)，首先會比較兩者的ZXID，均爲0，再比較myid，此時Server2的myid最大，於是更新自己的投票爲(2, 0)，然後重新投票，對於Server2而言，其無須更新自己的投票，只是再次向集羣中所有機器發出上一次投票信息即可。

(4) 統計投票。每次投票後，服務器都會統計投票信息，判斷是否已經有過半機器接受到相同的投票信息，對於Server1、Server2而言，都統計出集羣中已經有兩臺機器接受了(2, 0)的投票信息，此時便認爲已經選出了Leader。

(5) 改變服務器狀態。一旦確定了Leader，每個服務器就會更新自己的狀態，如果是Follower，那麼就變更爲FOLLOWING，如果是Leader，就變更爲LEADING。

服務器運行時期的 Leader 選舉

在Zookeeper運行期間，即便當有非Leader服務器宕機或新加入，此時也不會影響Leader，但是一旦Leader服務器掛了，那麼整個集羣將暫停對外服務，進入新一輪Leader選舉，其過程和啓動時期的Leader選舉過程基本一致。假設正在運行的有Server1、Server2、Server3三臺服務器，當前Leader是Server2，若某一時刻Leader掛了，此時便開始Leader選舉。選舉過程如下：

(1)變更狀態。Leader掛後，餘下的非Observer服務器都會將自己的服務器狀態變更爲LOOKING，然後開始進入Leader選舉流程。

(2)每個Server會發出一個投票。在這個過程中，需要生成投票信息(myid,ZXID)每個服務器上的ZXID可能不同，我們假定Server1的ZXID爲123，而Server3的ZXID爲122；在第一輪投票中，Server1和Server3都會投自己，產生投票(1, 123)，(3, 122)，然後各自將投票發送給集羣中所有機器。

(3)接收來自各個服務器的投票。與啓動時過程相同。

(4)處理投票。與啓動時過程相同，此時，Server1將會成爲Leader。

(5)統計投票。與啓動時過程相同。

(6)改變服務器的狀態。與啓動時過程相同。

Leader選舉算法分析

在3.4.0後的Zookeeper的版本只保留了TCP版本的FastLeaderElection選舉算法。當一臺機器進入Leader選舉時，當前集羣可能會處於以下兩種狀態

當ZooKeeper集羣中的一臺服務器出現以下兩種情況之一時，就會開始進入Leader選舉。

• 服務器初始化啓動。

• 服務器運行期間無法和Leader保持連接。

而當一臺機器進入Leader選舉流程時，當前集羣也可能會處於以下兩種狀態。

• 集羣中本來就巳經存在一個Leader。

• 集羣中確實不存在Leader。

我們先來看第一種巳經存在Leader的情況。此種情況一般都是某臺機器啓動得較晚，在其啓動之前，集羣已經在正常工作，對這種情況，該機器試圖去選舉Leader時，會被告知當前服務器的Leader信息，對於該機器而言，僅僅需要和Leader機器建立起連接，並進行狀態同步即可。

下面我們重點來看在集羣中Leader不存在的情況下，如何進行Leader選舉。

開始第一次投票

通常有兩種情況會導致集羣中不存在Leader

• 一種情況是在整個服務器剛剛初始化啓動時，此時尚未產生一臺Leader服務器。

• 另一種情況就是在運行期間當前Leader所在的服務器掛了。

無論是哪種情況，此時集羣中的所有機器都處於一種試圖選舉出一個Leader的狀態，我們把這種狀態稱爲“LOOKING”，意思是說正在尋找Leader。當一臺服務器處於LOOKING狀態的時候，那麼它就會向集羣中所有其他機器發送消息，我們稱這個消息爲“投票”。

在這個投票消息中包含兩個最基本的信息：

所推舉的服務器的SID和ZXID,分別表示了被推舉服務器的唯一標識和事務ID。

下文中我們將以“（SID, ZXID)”這樣的形式 來標識一次投票信息。舉例來說，如果當前服務器要推舉SID爲1、ZXID爲8的服務器成爲Leader,那麼它的這次投票信息可以表示爲（1，8）。

我們假設ZooKeeper由5臺機器組成，SID分別爲1、2、3、4和5, ZXID分別爲9、9、9、8和8,並且此時SID爲2的機器是Leader服務器。某一時刻，1和2所在的機器出現故障，因此集羣開始進行Leader選舉。

在第一次投票的時候，由於還無法檢測到集羣中其他機器的狀態信息，因此每臺機器都是將自己作爲被推舉的對象來進行投票，於是SID爲3、4和5的機器，投票情況分別爲：（3, 9）、（4, 8）和（5, 8）。

變更投票

集羣中的每臺機器發出自己的投票後，也會接收到來自集羣中其他機器的投票。每臺機器都會根據一定的規則，來處理收到的其他機器的投票，並以此來決定是否需要變更自己的投票。這個規則也成爲了整個Leader選舉算法的核心所在。爲了便於描述，我們首先定義一些術語。

• vote_sid：接收到的投票中所推舉Leader服務器的SID。

• vote_zxid：接收到的投票中所推舉Leader服務器的ZXID，既事物ID。

• self_sid:：當前服務器自己的SID。

• self_zxid：當前服務器自己的ZXID。

每次對於收到的投票的處理，都是一個對（votesid，votezxid)和（selfsid，selfzxid) 對比的過程，假設Epoch相同的情況下。

規則如下：

1、如果votezxid大於自己的selfzxid，就認可當前收到的投票，並再次將該投票發送出去。

2、如果votezxid小於自己的selfzxid,那麼就堅持自己的投票，不做任何變更。

3、如果votezxid等於自己的selfzxid,那麼就對比兩者的SID。如果votesid大於selfsid，那麼就認可當前接收到的投票，並再次將該投票發送出去。

4、如果votezxid等於自己的selfzxid，並且votesid小於selfsid，那麼同樣堅持自己的投票，不做變更。

根據上面這個規則，我們結合圖來分折上面提到的5臺機器組成的ZooKeeper集羣的投票變更過程。

 

每臺機器都把投票發出後，同時也會接收到來自另外兩臺機器的投票。

對幹Server3來說，它接收到了（4, 8）和（5, 8）兩個投票，對比後，由子自己的ZXID要大於接收到的兩個投票，因此不需要做任何變更。

對於Server4來說，它接收到了（3, 9）和（5, 8）兩個投票，對比後，由於（3, 9）這個投票的ZXID大於自己，因此需要變更投票爲（3, 9）,然後繼續將這個投票發送給另外兩臺機器。

同樣，對TServer5來說，它接收到了（3, 9）和（4, 8）兩個投票，對比後，由於（3, 9）這個投票的ZXID大於自己，因此需要變更投票爲（3, 9），然後繼續將這個投票發送給另外兩臺機器。

確定Leader

經過這第二次投票後，集羣中的每臺機器都會再次收到其他機器的投票，然後開始統計投票。如果一臺機器收到了超過半數的相同的投票，那麼這個投票對應的SID機器即爲 Leader。

如上圖所示的Leader選舉例子中，因爲ZooKeeper集羣的總機器數爲5臺，那麼 quorum = ( 5/2 + 1 ) = 3

也就是說，只要收到3個或3個以上（含當前服務器自身在內）一致的投票即可。在這裏，Server3、Server4 和Server5 都投票（3, 9），因此確定了 Server3爲 Leader。

小結

簡單地說，通常哪臺服務器上的數據越新（ZXID會越大），那麼越有可能成爲Leader,原因很簡單，數據越新，那麼它的ZXID也就越大，也就越能夠保證數據的恢復。當然，如果集羣中有幾個服務器有相同的ZXID，那麼SID較大的那臺服務器成爲Leader。

Leader選舉實現細節

1、服務器狀態

服務器具有四種狀態，分別是LOOKING、FOLLOWING、LEADING、OBSERVING。

• LOOKING：尋找Leader狀態。當服務器處於該狀態時，它會認爲當前集羣中沒有Leader，因此需要進入Leader選舉狀態。

• FOLLOWING：跟隨者狀態。表明當前服務器角色是Follower。

• LEADING：領導者狀態。表明當前服務器角色是Leader。

• OBSERVING：觀察者狀態。表明當前服務器角色是Observer。

2、投票數據結構

每個投票中包含了兩個最基本的信息，所推舉服務器的SID和ZXID，投票（Vote）在Zookeeper中包含字段如下。

• id：被推舉的Leader的SID。

• zxid：被推舉的Leader事務ID。

• electionEpoch：邏輯時鐘，用來判斷多個投票是否在同一輪選舉週期中，該值在服務端是一個自增序列，每次進入新一輪的投票後，都會對該值進行加1操作。

• peerEpoch：被推舉的Leader的epoch。

• state：當前服務器的狀態。

3、QuorumCnxManager：網絡I/O

每臺服務器在啓動的過程中，會啓動一個QuorumPeerManager，負責各臺服務器之間的底層Leader選舉過程中的網絡通信。

(1)消息隊列。QuorumCnxManager內部維護了一系列的隊列，用來保存接收到的、待發送的消息以及消息的發送器，除接收隊列以外，其他隊列都按照SID分組形成隊列集合，如一個集羣中除了自身還有3臺機器，那麼就會爲這3臺機器分別創建一個發送隊列，互不干擾。

• recvQueue：消息接收隊列，用於存放那些從其他服務器接收到的消息。

• queueSendMap：消息發送隊列，用於保存那些待發送的消息，按照SID進行分組。

• ·senderWorkerMap：發送器集合，每個SenderWorker消息發送器，都對應一臺遠程Zookeeper服務器，負責消息的發送，也按照SID進行分組。

• lastMessageSent：最近發送過的消息，爲每個SID保留最近發送過的一個消息。

(2)建立連接。爲了能夠相互投票，Zookeeper集羣中的所有機器都需要兩兩建立起網絡連接。QuorumCnxManager在啓動時會創建一個ServerSocket來監聽Leader選舉的通信端口(默認爲3888)。開啓監聽後，Zookeeper能夠不斷地接收到來自其他服務器的創建連接請求，在接收到其他服務器的TCP連接請求時，會進行處理。爲了避免兩臺機器之間重複地創建TCP連接，Zookeeper只允許SID大的服務器主動和其他機器建立連接，否則斷開連接。在接收到創建連接請求後，服務器通過對比自己和遠程服務器的SID值來判斷是否接收連接請求，如果當前服務器發現自己的SID更大，那麼會斷開當前連接，然後自己主動和遠程服務器建立連接。一旦連接建立，就會根據遠程服務器的SID來創建相應的消息發送器SendWorker和消息接收器RecvWorker，並啓動。

(3)消息接收與消息發送。

消息接收：由消息接收器RecvWorker負責，由於Zookeeper爲每個遠程服務器都分配一個單獨的RecvWorker，因此，每個RecvWorker只需要不斷地從這個TCP連接中讀取消息，並將其保存到recvQueue隊列中。

消息發送：由於Zookeeper爲每個遠程服務器都分配一個單獨的SendWorker，因此，每個SendWorker只需要不斷地從對應的消息發送隊列中獲取出一個消息發送即可，同時將這個消息放入lastMessageSent中。在SendWorker中，一旦Zookeeper發現針對當前服務器的消息發送隊列爲空，那麼此時需要從lastMessageSent中取出一個最近發送過的消息來進行再次發送，這是爲了解決接收方在消息接收前或者接收到消息後服務器掛了，導致消息尚未被正確處理。同時，Zookeeper能夠保證接收方在處理消息時，會對重複消息進行正確的處理。

4、FastLeaderElection：選舉算法核心

• 外部投票：特指其他服務器發來的投票。

• 內部投票：服務器自身當前的投票。

• 選舉輪次：Zookeeper服務器Leader選舉的輪次，即logicalclock。

• PK：對內部投票和外部投票進行對比來確定是否需要變更內部投票。

(1) 選票管理

• sendqueue：選票發送隊列，用於保存待發送的選票。

• recvqueue：選票接收隊列，用於保存接收到的外部投票。

• WorkerReceiver：選票接收器。其會不斷地從QuorumCnxManager中獲取其他服務器發來的選舉消息，並將其轉換成一個選票，然後保存到recvqueue中，在選票接收過程中，如果發現該外部選票的選舉輪次小於當前服務器的，那麼忽略該外部投票，同時立即發送自己的內部投票。

• WorkerSender：選票發送器，不斷地從sendqueue中獲取待發送的選票，並將其傳遞到底層QuorumCnxManager中。

(2) 算法核心

 

上圖展示了FastLeaderElection模塊是如何與底層網絡I/O進行交互的。Leader選舉的基本流程如下

1、自增選舉輪次。Zookeeper規定所有有效的投票都必須在同一輪次中，在開始新一輪投票時，會首先對logicalclock進行自增操作。

2、初始化選票。在開始進行新一輪投票之前，每個服務器都會初始化自身的選票，並且在初始化階段，每臺服務器都會將自己推舉爲Leader。

3、發送初始化選票。完成選票的初始化後，服務器就會發起第一次投票。Zookeeper會將剛剛初始化好的選票放入sendqueue中，由發送器WorkerSender負責發送出去。

4、接收外部投票。每臺服務器會不斷地從recvqueue隊列中獲取外部選票。如果服務器發現無法獲取到任何外部投票，那麼就會立即確認自己是否和集羣中其他服務器保持着有效的連接，如果沒有連接，則馬上建立連接，如果已經建立了連接，則再次發送自己當前的內部投票。

5、判斷選舉輪次。在發送完初始化選票之後，接着開始處理外部投票。在處理外部投票時，會根據選舉輪次來進行不同的處理。

• 外部投票的選舉輪次大於內部投票。若服務器自身的選舉輪次落後於該外部投票對應服務器的選舉輪次，那麼就會立即更新自己的選舉輪次(logicalclock)，並且清空所有已經收到的投票，然後使用初始化的投票來進行PK以確定是否變更內部投票。最終再將內部投票發送出去。

• 外部投票的選舉輪次小於內部投票。若服務器接收的外選票的選舉輪次落後於自身的選舉輪次，那麼Zookeeper就會直接忽略該外部投票，不做任何處理，並返回步驟4。

• 外部投票的選舉輪次等於內部投票。此時可以開始進行選票PK。

6、選票PK。在進行選票PK時，符合任意一個條件就需要變更投票。

• 若外部投票中推舉的Leader服務器的選舉輪次大於內部投票，那麼需要變更投票。

• 若選舉輪次一致，那麼就對比兩者的ZXID，若外部投票的ZXID大，那麼需要變更投票。

• 若兩者的ZXID一致，那麼就對比兩者的SID，若外部投票的SID大，那麼就需要變更投票。

7、變更投票。經過PK後，若確定了外部投票優於內部投票，那麼就變更投票，即使用外部投票的選票信息來覆蓋內部投票，變更完成後，再次將這個變更後的內部投票發送出去。

8、選票歸檔。無論是否變更了投票，都會將剛剛收到的那份外部投票放入選票集合recvset中進行歸檔。recvset用於記錄當前服務器在本輪次的Leader選舉中收到的所有外部投票（按照服務隊的SID區別，如{(1, vote1), (2, vote2)...}）。

9、統計投票。完成選票歸檔後，就可以開始統計投票，統計投票是爲了統計集羣中是否已經有過半的服務器認可了當前的內部投票，如果確定已經有過半服務器認可了該投票，則終止投票。否則返回步驟4。

10、更新服務器狀態。若已經確定可以終止投票，那麼就開始更新服務器狀態，服務器首選判斷當前被過半服務器認可的投票所對應的Leader服務器是否是自己，若是自己，則將自己的服務器狀態更新爲LEADING，若不是，則根據具體情況來確定自己是FOLLOWING或是OBSERVING。

以上10個步驟就是FastLeaderElection的核心，其中步驟4-9會經過幾輪循環，直到有Leader選舉產生。

部分參考摘抄：倪超 著《從Paxos到Zookeeper  分佈式一致性原理與實踐 》