zookeeper選舉機制

假設現在有5臺伺服器組成了zookeeper叢集

第一次啟動

1. 伺服器1啟 動，發起一次選舉。伺服器1投自己一票。此時伺服器1票數一票，不夠半數以上（3票），選舉無法完成，伺服器1狀態保持為LOOKING
2. 伺服器2啟動，再發起一次選舉。伺服器1和2分別投自己一票並交換選票資訊：此時伺服器1發現伺服器2的myid比自己目前投票推舉的（伺服器1）大，更改選票為推舉伺服器2。此時伺服器1票數0票，伺服器2票數2票，沒有半數以上結果，選舉無法完成，伺服器1，2狀態保持LOOKING
3. 伺服器3啟動，發起一次選舉。此時伺服器1和2都會更改選票為伺服器3（伺服器3的myid更大）。此次投票結果：伺服器1為0票，伺服器2為0票，伺服器3為3票。此時伺服器3的票數已經超過半數，伺服器3當選Leader。伺服器1，2更改狀態為FOLLOWING，伺服器3更改狀態LEADING
4. 伺服器4啟動，發起一次選舉。此時伺服器1，2，3已經不是LOOKING狀態，不會更改選票資訊。交換選票資訊結果：伺服器3為3票，伺服器4為 1票。此時伺服器4服從多數，更改選票資訊為伺服器3，並更改狀態為FOLLOWING
5. 伺服器5啟動，同4一樣當小弟

三個概念

在介紹非第一次啟動選舉機制前先介紹三個概念

• SID：伺服器ID。用來唯一標識一臺ZooKeeper叢集中的機器，每臺機器不能重複，和myid一致
• ZXID：事務ID。ZXID是一個事務ID，用來標識一次伺服器狀態的變更。在某一時刻，叢集中的每臺機器的ZXID值不一定完全一致，這和ZooKeeper伺服器對於客戶端"更新請求"的處理邏輯有關
• Epoch：每個Leader任期的代號。沒有Leader時同一輪投票過程中的邏輯時鐘值是相同的。每投完一次票這個資料就會增加

非第一次啟動

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

• 伺服器初始化啟動
• 伺服器執行期間無法和Leader保持連線

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

• 叢集中本來就已經存在一個Leader。

對於已經存在Leader的情況，機器試圖去選舉Leader時，會被告知當前伺服器的Leader資訊，對於該機器來說，僅僅需要和Leader機器建立連線，並進行狀態同步即可

• 叢集中確實不存在Leader

假設ZooKeeper由5臺伺服器組成，SID分別為1、2、3、4、5，ZXID分別為8、8、8、7、7，EPOCH分別為1、1、1、1、1，並且此時SID為3的伺服器是Leader。某一時刻，3和5伺服器出現故障，因此開始進行Leader選舉

此時剩下1、2、4伺服器，SID、ZXID、EPOCH值為：

SID  ZXID EPOCH
 1    8     1
 2    8     1
 4    7     1

選舉Leader規則

• EPOCH大的直接勝出
• EPOCH相同，事務id大的勝出
• 事務id相同，伺服器id大的勝出

此時，伺服器2選舉為leader