zookeeper領導者選舉原始碼分析

基於版本3.4.13

quorumcnxmanager主要負責和其他節點資料傳輸

sendqueue：選票傳送佇列，用於儲存待傳送的選票。

recvqueue：選票接收佇列，用於儲存接收到的外部投票。

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

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

recvqueue：當前節點接受資訊的列隊

senderworkermap：每台節點對應的senderworker，，long為伺服器myid，sendworker用於從queuesendmap存的queue取資料傳送給其他節點的，是個執行緒

注意圖里的recvqueue(fastleaderelection類中)佇列和recvqueue(quorumcnxmanager類中)是不一樣的。

quorumpeermain.main —> initializeandrun方法—>runfromconfig方法裡 quorumpeer.start() 啟動quorumpeer這個執行緒

quorumpeer類：

@override
public
synchronized
void
start()

**位於quorumpeer的run方法

伺服器有四種狀態，分別是looking、following、leading、observing。

每個投票中包含了兩個最基本的資訊，所推舉伺服器的sid和zxid，投票（vote）在zookeeper中包含字段如下

在3.4.0後的zookeeper的版本只保留了fastleaderelection選舉演算法。

上圖展示了fastleaderelection模組是如何與底層網路i/o進行互動的。leader選舉的基本流程如下

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

初始化選票。在開始進行新一輪投票之前，每個伺服器都會初始化自身的選票，並且在初始化階段，每台伺服器都會將自己推舉為leader。

傳送初始化選票。完成選票的初始化後，伺服器就會發起第一次投票。zookeeper會將剛剛初始化好的選票放入sendqueue中，由傳送器workersender負責傳送出去。

fastleaderelection類的lookforleader方法

public vote lookforleader()
throws interruptedexception 
// 把投票傳送出去，寫到sendqueue
sendnotifications()
;...
}

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

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

選票pk。在進行選票pk時，符合任意乙個條件就需要變更投票。

變更投票。經過pk後，若確定了外部投票優於內部投票，那麼就變更投票，即使用外部投票的選票資訊來覆蓋內部投票，變更完成後，再次將這個變更後的內部投票傳送出去。

選票歸檔。無論是否變更了投票，都會將剛剛收到的那份外部投票放入選票集合recvset中進行歸檔。recvset用於記錄當前伺服器在本輪次的leader選舉中收到的所有外部投票（按照服務隊的sid區別，如）。

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

更新伺服器狀態。若已經確定可以終止投票，那麼就開始更新伺服器狀態，伺服器首選判斷當前被過半伺服器認可的投票所對應的leader伺服器是否是自己，若是自己，則將自己的伺服器狀態更新為leading，若不是，則根據具體情況來確定自己是following或是observing。

以上10個步驟就是fastleaderelection的核心，其中步驟4-9會經過幾輪迴圈，直到有leader選舉產生。