[[355622]]

 本文轉載自微信公眾號「愛笑的架構師」，作者雷架 。轉載本文請聯系愛笑的架構師公眾號。

Zookeeper 是一個分布式服務框架，主要是用來解決分布式應用中遇到的一些數據管理問題如：統一命名服務、狀態同步服務、集群管理、分布式應用配置項的管理等。

我們可以簡單把 Zookeeper 理解為分布式家庭的大管家，那么管家團隊是如何選出Leader的呢?好奇嗎，接下來帶領大家一探究竟。

人類選舉的基本原理

講解 Zookeeper 選舉過程前先來介紹一下人類的選舉。

我們每個人或多或少都經歷過幾次選舉，在投票的過程中可能會遇到這樣幾種情況：

情況1：自己與幾個候選人都比較熟，你會將票投給你認為能力比較強的人;

熟人選舉

情況2：自己也是候選人，并且與其他幾個候選人都不熟，這個時候你肯定想著要去拉票，因為覺得自己才是最厲害的人呀，所有人都應該把票投給我。但是遺憾的是在拉票的過程中，你發現別人比你強，你開始自卑了，最終還是把票投給了自己認為最強的人。

自己參與選舉

所有人都投完票之后，最后從投票箱中進行統計，獲得票數最多的人當選。

思維導圖

在整個投票過程中我們可以提煉出四個最核心的概念：

• 候選人能力：投票的基本原則是選最強的人。
• 遇強改投：如果后面發現更強的人可以改投票。
• 投票箱：所有人的票都會放在投票箱。
• 領導者：得票最多的人即為領導者。

從人類選舉的原理我們來簡單推導一下Zookeeper的選舉原理。

Zookeeper選舉的基本原理

注意如果 Zookeeper 是單機部署是不需要選舉的，集群模式下才需要選舉。

Zookeeper 的選舉原理和人類選舉的邏輯類似，套用一下人類選舉的四個基本概念詳細解釋一下Zookeeper。

個人能力

如何衡量 Zookeeper 節點個人能力?答案是靠數據是否夠新，如果節點的數據越新就代表這個節點的個人能力越強，是不是感覺很奇怪，就是這么定的!

在 Zookeeper 中通常是以事務id(后面簡稱zxid)來標識數據的新舊程度(版本)，節點最新的zxid越大代表這個節點的數據越新，也就代表這個節點能力越強。

zxid 的全稱是 ZooKeeper Transaction Id，即 Zookeeper 事務id。

遇強改投

在集群選舉開始時，節點首先認為自己是最強的(即數據是最新的)，然后在選票上寫上自己的名字(包括zxid和sid)，zxid 是事務id，sid 唯一標識自己。

緊接著會將選票傳遞給其他節點，同時自己也會接收其他節點傳過來的選票。每個節點接收到選票后會做比較，這個人是不是比我強(zxid比我大)，如果比較強，那我就需要改票，明明別人比我強，我也不能厚著臉皮對吧。

投票箱

與人類選舉投票箱稍微有點不一樣，Zookeeper 集群會在每個節點的內存中維護一個投票箱。節點會將自己的選票以及其他節點的選票都放在這個投票箱中。由于選票是互相傳閱的，所以最終每個節點投票箱中的選票會是一樣的。

領導者

在投票的過程中會去統計是否有超過一半的選票和自己選擇的是同一個節點，即都認為某個節點是最強的。一旦集群中有超過半數的節點都認為某個節點最強，那該節點就是領導者了，投票也宣告結束。

什么場景下 Zookeeper 需要選舉?

當 Zookeeper 集群中的一臺服務器出現以下兩種情況之一時，需要進入 Leader 選舉。

(1)服務器初始化啟動。

(2)服務器運行期間 Leader 故障。

啟動時期的 Leader 選舉

假設一個 Zookeeper 集群中有5臺服務器，id從1到5編號，并且它們都是最新啟動的，沒有歷史數據。

集群剛啟動選舉過程

假設服務器依次啟動，我們來分析一下選舉過程：

(1)服務器1啟動

發起一次選舉，服務器1投自己一票，此時服務器1票數一票，不夠半數以上(3票)，選舉無法完成。

投票結果：服務器1為1票。

服務器1狀態保持為LOOKING。

(2)服務器2啟動

發起一次選舉，服務器1和2分別投自己一票，此時服務器1發現服務器2的id比自己大，更改選票投給服務器2。

投票結果：服務器1為0票，服務器2為2票。

服務器1，2狀態保持LOOKING

(3)服務器3啟動

發起一次選舉，服務器1、2、3先投自己一票，然后因為服務器3的id最大，兩者更改選票投給為服務器3;

投票結果：服務器1為0票，服務器2為0票，服務器3為3票。此時服務器3的票數已經超過半數(3票)，服務器3當選Leader。

服務器1，2更改狀態為FOLLOWING，服務器3更改狀態為LEADING。

(4)服務器4啟動

發起一次選舉，此時服務器1，2，3已經不是LOOKING 狀態，不會更改選票信息。交換選票信息結果：服務器3為3票，服務器4為1票。此時服務器4服從多數，更改選票信息為服務器3。

服務器4并更改狀態為FOLLOWING。

(5)服務器5啟動

與服務器4一樣投票給3，此時服務器3一共5票，服務器5為0票。

服務器5并更改狀態為FOLLOWING。

最終的結果：

服務器3是 Leader，狀態為 LEADING;其余服務器是 Follower，狀態為 FOLLOWING。

運行時期的Leader選舉

在 Zookeeper運行期間 Leader 和 非 Leader 各司其職，當有非 Leader 服務器宕機或加入不會影響 Leader，但是一旦 Leader 服務器掛了，那么整個 Zookeeper 集群將暫停對外服務，會觸發新一輪的選舉。

初始狀態下服務器3當選為Leader，假設現在服務器3故障宕機了，此時每個服務器上zxid可能都不一樣，server1為99，server2為102，server4為100，server5為101

集群 Leader 節點故障

運行期選舉與初始狀態投票過程基本類似，大致可以分為以下幾個步驟：

(1)狀態變更。Leader 故障后，余下的非 Observer 服務器都會將自己的服務器狀態變更為LOOKING，然后開始進入Leader選舉過程。

(2)每個Server會發出投票。

(3)接收來自各個服務器的投票，如果其他服務器的數據比自己的新會改投票。

(4)處理和統計投票，每一輪投票結束后都會統計投票，超過半數即可當選。

(5)改變服務器的狀態，宣布當選。

話不多說先來一張圖：

運行器 Leader 故障后選舉流程

(1)第一次投票，每臺機器都會將票投給自己。

(2)接著每臺機器都會將自己的投票發給其他機器，如果發現其他機器的zxid比自己大，那么就需要改投票重新投一次。比如server1 收到了三張票，發現server2的xzid為102，pk一下發現自己輸了，后面果斷改投票選server2為老大。

選舉機制中涉及到的核心概念

敲黑板了，這些概念是面試必考的。

(1)Server id(或sid)：服務器ID

比如有三臺服務器，編號分別是1,2,3。編號越大在選擇算法中的權重越大，比如初始化啟動時就是根據服務器ID進行比較。

(2)Zxid：事務ID

服務器中存放的數據的事務ID，值越大說明數據越新，在選舉算法中數據越新權重越大。

(3)Epoch：邏輯時鐘

也叫投票的次數，同一輪投票過程中的邏輯時鐘值是相同的，每投完一次票這個數據就會增加。

(4)Server狀態：選舉狀態

LOOKING，競選狀態。

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

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

LEADING，領導者狀態。

總結

(1)Zookeeper 選舉會發生在服務器初始狀態和運行狀態下。

(2)初始狀態下會根據服務器sid的編號對比，編號越大權值越大，投票過半數即可選出Leader。

(3)Leader 故障會觸發新一輪選舉，zxid 代表數據越新，權值也就越大。

(4)在運行期選舉還可能會遇到腦裂的情況，大家可以自行學習。