棧長面試經常會遇到面試官問 Zookeeper 的選舉原理，我心想，問這些有啥用嗎？又不要我造火箭！
每次面試也只知道個大概，並沒有深究具體的流程，所以在面試的時候總是不能打動面試官，總是特別喫虧，所以這篇就總結一下其中的要點，也希望能幫助大家搞定面試。
有一說一， Zookeeper 這些工作原理、選舉流程，也許大多數人在工作中不會用到，但瞭解多一點也是自己的優勢，避免求職面試被面試官打壓工資。Zookeeper 也是現在後端主流的分佈式協調框架，很多熱門框架都有直接或者間接依賴它，比如：Dubbo、Elastic Job、Kafka 等，所以掌握 ZK 選舉流程也是非常有必要的。
本文會以通俗易懂的方式進行， ZK 小白也能看懂。另外，我也將 Zookeeper 系列主流面試題和參考答案都整理好了，關注公衆號Java技術棧回覆關鍵字 "面試" 進行刷題。
基本概念
瞭解選舉前你得了解一些 Zookeeper 的基本概念。
集羣機器 ID
集羣機器 ID 是指 myid，它是每一個集羣機器中的編號文件，代表 ZooKeeper 集羣服務器的標識，手動生成，全局全一。
事務 ID
事務 ID 是指 zxid，Zookeeper 會給每個更新請求分配一個事務 ID，它是一個 64 位的數字，由 Leader 統一進行分配，全局唯一，不斷遞增，在一個節點的狀態信息中可以查看到最新的事務 ID 信息。
集羣服務器角色
Zookeeper 集羣服務器有以下 3 種角色：
1、Leader（主）
2、Follower（從，參與投票）
3、Observer（觀察者，不參與投票）
集羣服務器狀態
Zookeeper 集羣服務器有以下 4 種狀態：
1、LOOKING
尋找 Leader 狀態，當服務器處於該狀態時，表示當前集羣沒有 Leader，因此會進入 Leader 選舉狀態。
2、FOLLOWING
跟隨者狀態，表示當前服務器角色是 Follower。
3、LEADING
領導者狀態，表示當前服務器角色是 Leader。
4、OBSERVING
觀察者狀態，表示當前服務器角色是 Observer。
選舉方式
Zookeeper 提供了 3 種選舉方式：
- LeaderElection
- AuthFastLeaderElection
- FastLeaderElection （最新默認）
選舉場景
Zookeeper 會在以下場景進行選舉：
1、Zookeeper 集羣啓動初始化時進行選舉
2、Zookeeper 集羣 Leader 失聯時重新選舉
選舉前提條件
1、Zookeeper 服務器處於 LOOKING 競選狀態
此時說明 Zookeeper 服務器集羣處於羣龍無首狀態，另外，觀察者狀態不能參與競選投票。
2、Zookeeper 集羣規模至少要 3 臺機器或以上
集羣規則爲：2N + 1臺，N > 0，即最少需要 3 臺，因爲 ZK 集羣的機制是隻要超過半數的節點正常，集羣就能正常提供服務。只有在 ZK 節點掛得太多，只剩一半或不到一半節點能工作時，集羣纔會失效。
如以下分析所示：
3 個節點的 Cluster 可以掛掉 1 個節點（Leader 可以得到 2 票 > 1.5)
2 個節點的 Cluster 就不能掛掉任何 1 個節點了（Leader 可以得到 1 票 <= 1)
所以你知道 ZK 集羣爲什麼至少要 3 臺了吧？
3、Zookeeper 集羣要 2 臺及以上機器可以互相通信
只要達到 2 臺服務器通信了才能進行選舉，只有一臺服務器啓動時無法進行選舉，因爲服務器之間通信了纔可以互相同步投票結果。
選舉流程
1、集羣初始選舉
Zookeeper 在集羣啓動時會進行選舉，這裏拿 3 臺服務器進行舉例：
| server | myid | zxid |
|---|---|---|
| zk1 | 1 | 0 |
| zk2 | 2 | 0 |
| zk3 | 3 | 0 |
依次啓動 3 臺服務器 zk1, zk2, zk3，初始情況下事務 ID 都爲 0。
選舉大致流程：
1、初始投票
服務器啓動後，每個 Server 都會給自己投上一票，每次投票會包含所投票服務器的 myid 和 zxid，這裏使用 Server（myid, zxid）的方式表示，此時的投票結果爲：zk1（1, 0），zk2（2, 0），zk3（3, 0）
2、同步投票結果
集羣中的服務器在投票後，會將各自的投票結果同步給集羣中其他服務器。
3、檢查投票有效性
各服務器在收到投票後會檢查投票的有效性，如：是否本輪投票，是否來自 LOOKING 狀態的服務器的投票等。
4、處理投票
服務器之間會進行投票比對，規則如下：
- 優先檢查 zxid，較大的服務器優先作爲 Leader
- 如果 zxid 相同，則 myid 較大的服務器作爲 Leader
如：zk1 和 zk2 進行比對，此時 zk2 勝出，zk1 更新自己的投票爲：zk1（2, 0）
5、統計投票結果
每輪投票比對之後都會統計投票結果，確認是否有超過半數的機器都得到相同的投票結果，如果是，則選出 Leader，否則繼續投票。
本輪選舉中，zk1 和 zk2 都得到了相同的投票結果（2, 0），2 指 zk2，並且超過了半數的機器（2 > 3 / 2），所以此時 zk2 就成爲了本輪選舉的 Leader。
所以，即使 zk3 啓動了，因爲集羣已經有了 Leader，所以選舉也結束了，zk3 不再參與選舉，後面進來的都是小弟。
6、更改服務器狀態
一旦選出 Leader，每個服務器就會各自更新自己的狀態：
zk1 >>> FOLLOWING
zk2 >>> LEADING
Zk3 >>> FOLLOWING
2、集羣重新選舉
Zookeeper 集羣運行期間無法和 Leader 保持正常連接時，即如果 Leader 掛了，或者 Leader 服務器故障都會進行新一輪的 Leader 選舉。
這裏還是拿 3 臺服務器進行舉例：
| server | myid | zxid |
|---|---|---|
| zk1（Follower） | 1 | 0 |
| zk2（Leader） | 2 | 0 |
| zk3（Follower） | 3 | 0 |
如果作爲初始選舉的 Leader zk2 掛了，集羣就會暫停對外提供服務，從而進行新的 Leader 選舉。
選舉大致過程：
1、狀態變更
既然過去的老大 Leader 不可用了，那所有的 Follower 服務器就需要從 FOLLOWING 狀態變更爲：LOOKING，開始新的一輪 Leader 選舉。
2、開始投票
投票邏輯和啓動初始時一致。
zk1, zk3 第一輪投票默認還是會先投給自己，zk2 掛了不能進行投票。
第一輪投票結果爲：zk1（1, 66）、zk3（3, 28），zk1 和 zk3 各得一票，這裏假設 zk1 事務 ID 比 zk3 更大一點。
3、同步投票結果
同步投票邏輯和啓動初始時一致。
4、檢查投票有效性
檢查投票邏輯和啓動初始時一致。
5、處理投票
處理投票邏輯和啓動初始時一致。
此時 zk1 和 zk3 進行比對，根據規則，由於 zk1 的事務 ID 更大一點，所以 zk1 勝出，zk3 也更新自己的投票爲：zk3（1, 28）
6、統計投票結果
統計投票邏輯和啓動初始時一致。
本輪選舉中，zk1 和 zk3 都得到了相同的投票結果 zk1，並且超過了半數的機器（2 > 3 / 2），所以此時 zk1 就成爲了本輪選舉的 Leader。
7、更改服務器狀態
更改狀態邏輯和啓動初始時一致。
總結
所以，我們可以總結下，Zookeeper 集羣按 myid 從小到大依次啓動初始化時，在超過半數機器的投票的情況下，誰的 myid 最大，誰就是 Leader，知道這個定律，不同的集羣規模我們都可以推算出誰是 Leader。
集羣初始化時：
1）集羣有 3 臺機器，第 2 大的 myid 所在服務器就是 Leader；
2）集羣有 4 臺機器，第 3 大的 myid 所在服務器就是 Leader；
3）集羣有 5 臺機器，第 3 大的 myid 所在服務器就是 Leader；
3）集羣有 6 臺機器，第 4 大的 myid 所在服務器就是 Leader；
.....
集羣重新選舉時，根據 myid 和 zxid 的大小共同決斷，zxid 更大的優先成爲 Leader。
總之，誰得到半數以上的服務器支持，誰就是老大，Zookeeper 選舉流程你看懂了嗎？這只是粗略版的選舉流程，實際選舉過程要更復雜，有興趣的可以深入研究下源碼。
好了，今天的分享就到這裏了，後面棧長會分享更多好玩的 Java 技術和最新的技術資訊，關注公衆號Java技術棧第一時間推送，我也將主流 Zookeeper 面試題和參考答案都整理好了，在公衆號後臺回覆關鍵字 "面試" 進行刷題。
最後，覺得我的文章對你用收穫的話，動動小手，給個在看、轉發，原創不易，棧長需要你的鼓勵。
版權聲明： 本文系公衆號 "Java技術棧" 原創，原創實屬不易，轉載、引用本文內容請註明出處，抄襲者一律舉報＋投訴，並保留追究其法律責任的權利。
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2021最新版)
2.別在再滿屏的 if/ else 了，試試策略模式，真香！！
3.臥槽！Java 中的 xx ≠ null 是什麼新語法？
4.Spring Boot 2.5 重磅發佈，黑暗模式太炸了！
覺得不錯，別忘了隨手點贊+轉發哦！