ZooKeeper 的 Leader 選舉

1. 前言

我們在 Zookeeper 集群模式一節中，我們學習了為什么要使用 Zookeeper 的集群模式，是因為我們需要保證 Zookeeper 服務的高性能和高可用性。既然使用 Zookeeper 的集群模式，那么避免不了的問題就是 Zookeeper 如何進行 Leader 的選舉以及和如何保證 Zookeeper 服務的數據一致性。那么本節我們就來講解 Zookeeper 服務是如何進行 Leader 選舉的。

2. Zookeeper 的 Leader 選舉

Zookeeper 的 Leader 選舉發生在兩個階段：

1. Zookeeper 服務初次啟動時的 Leader 選舉。
2. Zookeeper 崩潰恢復時的 Leader 選舉。

首先我們來講解在 Zookeeper 服務啟動時的 Leader 選舉。

2.1 Zookeeper 服務啟動時的 Leader 選舉

在 Zookeeper 服務啟動階段，每個 Zookeeper 服務會根據配置文件選擇啟動模式。

在選擇集群模式的情況下，獲取配置文件中所有 Zookeeper 服務的地址，然后向其它 Zookeeper 服務發起通信檢查，確認 Zookeeper 服務間的通信狀態。然后在這些 Zookeeper 服務間尋找 Leader 節點，初次啟動時無 Leader 節點，此時就會進入 Leader 選舉的狀態。

在選舉狀態中，所有 Zookeeper 服務的狀態都會變為 Looking 選舉狀態，每臺 Zookeeper 服務都把自己當作 Leader 候選者向其它 Zookeeper 服務發送自己的選票信息。我們這里以 3 個 Zookeeper 服務為例子：

選票信息包括 Zookeeper 的服務ID，也就是 myid 文件中的內容，還有就是 Zookeeper 服務最新的事務ID，也就是 ZXID，當然初次啟動的 Zookeeper 服務的事務 ID 都是相同的 。發送選票信息的同時，也會接收到其它 Zookeeper 服務發送的選票信息。

Tips： ZXID：節點本地的事務編號，由64位的數字組成，包含紀元值（ epoch ）和計數兩部分。

正常情況下，在第一輪的選舉中，每個 Zookeeper 服務的選票信息都是自身的信息，所以不會產生 Leader，此時就會開啟第二輪選舉。

在第二輪選舉之前，Zookeeper 服務會把自己的選票信息和接收到的其它 Zookeeper 服務的選票信息一起做比較，產生新的選票信息，首先比較 ZXID，選取擁有較大的 ZXID 的選票信息作為自己新的選票，如果 ZXID 相同，則會比較服務ID，也就是 myid 的值，選取擁有較大的 myid 值的選票信息作為自己新的選票。

產生了新的選票之后，發起第二輪投票，此時 Zookeeper 服務器會統計所有服務器發出的選票，如果超過半數的 Zookeeper 服務的選票信息是相同的，那么該選票中的 myid 值相對應的 Zookeeper 服務就當選為 Leader 服務，其狀態變為 Leading，其它 Zookeeper 服務的狀態由 Looking 狀態變為 Following，也就是 Follower 服務。如果選票的統計未達到半數以上，則更新各個節點的選票信息，重新開始新一輪的選舉，直到選舉出 Leader。

以上就是 Zookeeper 服務啟動時的 Leader 選舉的過程。接下來我們講解 Zookeeper 在崩潰恢復階段的 Leader 選舉。

2.2 Zookeeper 的 ZAB 協議

2.2.1 什么是 ZAB 協議

Zookeeper 使用 ZAB 協議來保證 Zookeeper 的數據一致性，ZAB 協議全稱 Zookeeper Atomic Broadcast ，原子消息廣播協議。

ZAB 協議的兩種工作模式：

1. 崩潰恢復
2. 消息廣播

ZAB 協議定義了三種節點狀態：

1. Looking：選舉狀態；
2. Following：從節點所處的狀態；
3. Leading：主節點所處的狀態。

那么 ZAB 協議的這兩種模式什么時候使用呢？三種節點的狀態又是如何變化的呢？

接下來，我們來詳細了解一下 ZAB 的崩潰恢復模式是如何工作的。

2.2.2 ZAB 的崩潰恢復模式

在 Zookeeper 集群服務的運行過程中，如果 Leader 節點發生故障，無法處理 Follower 節點提交的事務請求，根據 ZAB 協議，此時的 Zookeeper 集群就會暫時停止對外提供服務，進入崩潰恢復。如果此時崩潰的 Leader 服務故障被排除，加入到 Zookeeper 集群中，它也會進入 Looking 狀態，參與選舉。

Zookeeper 的崩潰恢復分為 3 個階段：

1. Leader election
   在 Leader 選舉階段，Zookeeper 服務都為 Looking 狀態，每個 Zookeeper 服務都會用自身的 ZXID 和 myid 值形成選票，第一輪選舉和 Zookeeper 啟動時第一輪選舉的結果一樣，Zookeeper 服務的選票信息都是自身的信息，所以不會產生 Leader，無 Leader 產生 Zookeeper 服務就會更新自身的選票信息，進入下一輪選舉，直到選舉出 Leader。

   這一階段選舉出來的 Leader 還不能直接作為真正的 Leader 去處理事務請求，它還需要再次確認自身的數據是最新的，避免網絡等原因出現多個 Leader 的情況，接下來就進入 Discovery 發現階段。

2. Discovery
   在 Discovery 發現階段，上一階段產生的 Follower 服務會把自身 ZXID 中的 epoch 紀元值發送給 Leader 服務，Leader 接收到所有 Follower 的 epoch 紀元值后，會選出其中最大的 epoch 紀元值，然后在這基礎上進行加 1 ，作為最新的 epoch 紀元值，返回給所有的 Follower 。

   Follower 接收到 Leader 發送的最新 epoch 紀元值后，根據此 epoch 紀元值來更新自己的 ZXID ，然后再把更新后的 ZXID 、最新的歷史事務日志和 ACK 確認信息返回到 Leader。

   Leader 接收到 ACK 確認信息后，把接收到最新的 ZXID 和 最新的歷史事務日志和自身作比較，把最新的更新到自身。

   經過這一階段就能確認 Leader 服務的數據是最新的了，然后就進入下一階段，Synchronization 同步階段。

3. Synchronization
   Synchronization 同步階段的主要作用是把 Leader 最新的數據和日志同步到 Follower 中，當半數以上的 Follower 同步數據成功后，Leader 才能成為真正的 Leader ，就可以處理事務請求了。

經過崩潰恢復的 3 個階段，真正的 Leader 選舉完成后，Zookeeper 就會進入消息廣播模式，重新對外提供服務。

3. 總結

經過本節的學習，我們知道了 Zookeeper 在啟動時和崩潰恢復時的 Leader 選舉時如何完成的，也了解了 Zookeeper 崩潰恢復的 3 個階段。以下是本節內容的總結：

1. Zookeeper 在啟動時的 Leader 選舉。
2. Zookeeper 的 ZAB 協議。
3. ZAB 協議的崩潰恢復過程。
4. Zookeeper 崩潰恢復的 3 個階段。