如果leader崩潰，Kafka怎樣重新選舉？

leader對(duì)于消息的寫入以及讀取是非常關(guān)鍵的，此時(shí)有兩個(gè)疑問：

1. Kafka如何確定某個(gè)partition是leader、哪個(gè)partition是follower呢?

2. 某個(gè)leader崩潰了，如何快速確定另外一個(gè)leader呢?因?yàn)镵afka的吞吐量很高、延遲很低，所以選舉leader必須非常快。

如果leader崩潰，Kafka會(huì)如何?

使用Kafka Eagle找到某個(gè)partition的leader，再找到leader所在的broker。在Linux中強(qiáng)制殺掉該Kafka的進(jìn)程，然后觀察leader的情況。

通過觀察，我們發(fā)現(xiàn)，leader在崩潰后，Kafka又從其他的follower中快速選舉出來了leader。

l Kafka啟動(dòng)時(shí)，會(huì)在所有的broker中選擇一個(gè)controller

l 前面leader和follower是針對(duì)partition，而controller是針對(duì)broker的

l 創(chuàng)建topic、或者添加分區(qū)、修改副本數(shù)量之類的管理任務(wù)都是由controller完成的

l Kafka分區(qū)leader的選舉，也是由controller決定的

Controller的選舉

l 在Kafka集群?jiǎn)?dòng)的時(shí)候，每個(gè)broker都會(huì)嘗試去ZooKeeper上注冊(cè)成為Controller(ZK臨時(shí)節(jié)點(diǎn))

l 但只有一個(gè)競(jìng)爭(zhēng)成功，其他的broker會(huì)注冊(cè)該節(jié)點(diǎn)的監(jiān)視器

l 一點(diǎn)該臨時(shí)節(jié)點(diǎn)狀態(tài)發(fā)生變化，就可以進(jìn)行相應(yīng)的處理

l Controller也是高可用的，一旦某個(gè)broker崩潰，其他的broker會(huì)重新注冊(cè)為Controller

找到當(dāng)前Kafka集群的controller

1. 點(diǎn)擊Kafka Tools的「Tools」菜單，找到「ZooKeeper Brower...」

2. 點(diǎn)擊左側(cè)樹形結(jié)構(gòu)的controller節(jié)點(diǎn)，就可以查看到哪個(gè)broker是controller了。

測(cè)試controller選舉

通過kafka tools找到controller所在的broker對(duì)應(yīng)的kafka進(jìn)程，殺掉該進(jìn)程，重新打開ZooKeeper brower，觀察kafka是否能夠選舉出來新的Controller。

Controller選舉partition leader

l 所有Partition的leader選舉都由controller決定

l controller會(huì)將leader的改變直接通過RPC的方式通知需為此作出響應(yīng)的Broker

l controller讀取到當(dāng)前分區(qū)的ISR，只要有一個(gè)Replica還幸存，就選擇其中一個(gè)作為leader否則，則任意選這個(gè)一個(gè)Replica作為leader

l 如果該partition的所有Replica都已經(jīng)宕機(jī)，則新的leader為-1

為什么不能通過ZK的方式來選舉partition的leader?

l Kafka集群如果業(yè)務(wù)很多的情況下，會(huì)有很多的partition

l 假設(shè)某個(gè)broker宕機(jī)，就會(huì)出現(xiàn)很多的partiton都需要重新選舉leader

l 如果使用zookeeper選舉leader，會(huì)給zookeeper帶來巨大的壓力。所以，kafka中l(wèi)eader的選舉不能使用ZK來實(shí)現(xiàn)。

為什么選擇kafka采集數(shù)據(jù)？

Kafka生產(chǎn)、消費(fèi)數(shù)據(jù)的工作流程

kafka自定義攔截器實(shí)例教程[傳智教育]

Zookeeper是如何選取主leader的？

傳智python+大數(shù)據(jù)開發(fā)培養(yǎng)新型數(shù)字化人才