歡迎跳轉到本文的原文鏈接：https://honeypps.com/mq/kafka-basic-knowledge-of-selection/

面試官在考查你Kafka知識的時候很可能會故弄玄虛的問你一下：Kafka中的選舉時怎么回事？除非問你具體的哪種選舉，否則問這種問題的面試官多半也是對Kafka一知半解，這個時候就是“弄死”他的時候。當然如果你沒有一定的知識儲備，那么就是你被“弄死”的時候。

一般問這個問題，那么他肯定知道其中的一種，比如分區leader的選舉。所謂分區leader的選舉就是當ISR中的leader副本歇菜了，再重新選舉一個的過程。對于這個問題就是你反客為主的機會，因為Kafka中的選舉有多處，可不止分區leader的選舉這一處，就算指明問分區leader的選舉，那么也需要分4種情況具體分析。而這里面的細節是大多數人不甚明了的。

Kafka中的選舉大致可以分為三大類：控制器的選舉、分區leader的選舉以及消費者相關的選舉，這里還可以具體細分為7個小類。我們一一來過一下，本文只是簡單羅列下大致的內容，至于內部具體的細節邏輯就需要靠讀者自己去探索啦。虐人還是被虐就靠你的自驅力了。

控制器的選舉

在Kafka集群中會有一個或多個broker，其中有一個broker會被選舉為控制器（Kafka Controller），它負責管理整個集群中所有分區和副本的狀態等工作。比如當某個分區的leader副本出現故障時，由控制器負責為該分區選舉新的leader副本。再比如當檢測到某個分區的ISR集合發生變化時，由控制器負責通知所有broker更新其元數據信息。

Kafka Controller的選舉是依賴Zookeeper來實現的，在Kafka集群中哪個broker能夠成功創建/controller這個臨時（EPHEMERAL）節點他就可以成為Kafka Controller。

這里需要說明一下的是Kafka Controller的實現還是相當復雜的，涉及到各個方面的內容，如果你掌握了Kafka Controller，你就掌握了Kafka的“半壁江山”。篇幅所限，這里就不一一展開了，有興趣的讀者可以查閱一下《深入理解Kafka》中第6章的相關內容。

分區leader的選舉

這里不說什么一致性協議（PacificA）相關的內容，只講述具體的選舉內容。

分區leader副本的選舉由Kafka Controller 負責具體實施。當創建分區（創建主題或增加分區都有創建分區的動作）或分區上線（比如分區中原先的leader副本下線，此時分區需要選舉一個新的leader上線來對外提供服務）的時候都需要執行leader的選舉動作。

基本思路是按照AR集合中副本的順序查找第一個存活的副本，并且這個副本在ISR集合中。一個分區的AR集合在分配的時候就被指定，并且只要不發生重分配的情況，集合內部副本的順序是保持不變的，而分區的ISR集合中副本的順序可能會改變。注意這里是根據AR的順序而不是ISR的順序進行選舉的。這個說起來比較抽象，有興趣的讀者可以手動關閉/開啟某個集群中的broker來觀察一下具體的變化。

還有一些情況也會發生分區leader的選舉，比如當分區進行重分配（reassign）的時候也需要執行leader的選舉動作。這個思路比較簡單：從重分配的AR列表中找到第一個存活的副本，且這個副本在目前的ISR列表中。

再比如當發生優先副本（preferred replica partition leader election）的選舉時，直接將優先副本設置為leader即可，AR集合中的第一個副本即為優先副本。

Kafka中有很多XX副本的稱呼，如果不是很了解，可以關注本系列的下一篇《Kafka科普系列 | Kafka中到底有多少種副本？》

還有一種情況就是當某節點被優雅地關閉（也就是執行ControlledShutdown）時，位于這個節點上的leader副本都會下線，所以與此對應的分區需要執行leader的選舉。這里的具體思路為：從AR列表中找到第一個存活的副本，且這個副本在目前的ISR列表中，與此同時還要確保這個副本不處于正在被關閉的節點上。

消費者相關的選舉

對于這部分內容的理解，額。。如果你對消費者、消費組、消費者協調器以及組協調器不甚理解的話，那么。。。職能毛遂自薦《深入理解Kafka》一書了，嘿嘿。

組協調器GroupCoordinator需要為消費組內的消費者選舉出一個消費組的leader，這個選舉的算法也很簡單，分兩種情況分析。如果消費組內還沒有leader，那么第一個加入消費組的消費者即為消費組的leader。如果某一時刻leader消費者由于某些原因退出了消費組，那么會重新選舉一個新的leader，這個重新選舉leader的過程又更“隨意”了，相關代碼如下：

//scala code. private val members = new mutable.HashMap[String, MemberMetadata] var leaderId = members.keys.head

解釋一下這2行代碼：在GroupCoordinator中消費者的信息是以HashMap的形式存儲的，其中key為消費者的member_id，而value是消費者相關的元數據信息。leaderId表示leader消費者的member_id，它的取值為HashMap中的第一個鍵值對的key，這種選舉的方式基本上和隨機無異?？傮w上來說，消費組的leader選舉過程是很隨意的。

插播：近日發現文章被盜的厲害，發文幾個小時文章就在各大門戶網站上出現，全都是標的原創。雖然沒有能力制止，但是我發現大多不仔細看直接抄的（有連我下面的公眾號二維碼也抄了去的，當然也有用PS來P掉我圖片水印的雞賊操作），所以機智的我。。不如在文章中插播一下我的書，讓他們盜了去也好替我宣傳宣傳。我是皮的很~~

到這里就結束了嗎？還有分區分配策略的選舉呢。

許你對此有點陌生，但是用過Kafka的同學或許對partition.assignment.strategy（取值為RangeAssignor、RoundRobinAssignor、StickyAssignor等）這個參數并不陌生。每個消費者都可以設置自己的分區分配策略，對消費組而言需要從各個消費者呈報上來的各個分配策略中選舉一個彼此都“信服”的策略來進行整體上的分區分配。這個分區分配的選舉并非由leader消費者決定，而是根據消費組內的各個消費者投票來決定的。至于具體的細節么。。。嘿嘿。

歡迎跳轉到本文的原文鏈接：https://honeypps.com/mq/kafka-basic-knowledge-of-selection/

---

歡迎支持筆者新作：《深入理解Kafka:核心設計與實踐原理》和《RabbitMQ實戰指南》，同時歡迎關注筆者的微信公眾號：朱小廝的博客。

總結

以上是生活随笔為你收集整理的Kafka科普系列 | 原来Kafka中的选举有这么多？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。