資料內(nèi)容：

Kafka核心總控制器Controller

在Kafka集群中會有一個或者多個broker，其中有一個broker會被選舉為控制器（Kafka Controller），它負(fù)責(zé)管理整個
集群中所有分區(qū)和副本的狀態(tài)。
當(dāng)某個分區(qū)的leader副本出現(xiàn)故障時，由控制器負(fù)責(zé)為該分區(qū)選舉新的leader副本。
當(dāng)檢測到某個分區(qū)的ISR集合發(fā)生變化時，由控制器負(fù)責(zé)通知所有broker更新其元數(shù)據(jù)信息。
當(dāng)使用kafka-topics.sh腳本為某個topic增加分區(qū)數(shù)量時，同樣還是由控制器負(fù)責(zé)讓新分區(qū)被其他節(jié)點感知
到。
 

Controller選舉機制

在kafka集群啟動的時候，會自動選舉一臺broker作為controller來管理整個集群，選舉的過程是集群中每個broker都會
嘗試在zookeeper上創(chuàng)建一個 /controller 臨時節(jié)點，zookeeper會保證有且僅有一個broker能創(chuàng)建成功，這個broker
就會成為集群的總控器controller。
當(dāng)這個controller角色的broker宕機了，此時zookeeper臨時節(jié)點會消失，集群里其他broker會一直監(jiān)聽這個臨時節(jié)
點，發(fā)現(xiàn)臨時節(jié)點消失了，就競爭再次創(chuàng)建臨時節(jié)點，就是我們上面說的選舉機制，zookeeper又會保證有一個broker
成為新的controller。
具備控制器身份的broker需要比其他普通的broker多一份職責(zé)，具體細(xì)節(jié)如下：
1. 監(jiān)聽broker相關(guān)的變化。為Zookeeper中的/brokers/ids/節(jié)點添加BrokerChangeListener，用來處理broker
增減的變化。
2. 監(jiān)聽topic相關(guān)的變化。為Zookeeper中的/brokers/topics節(jié)點添加TopicChangeListener，用來處理topic增減
的變化；為Zookeeper中的/admin/delete_topics節(jié)點添加TopicDeletionListener，用來處理刪除topic的動作。
3. 從Zookeeper中讀取獲取當(dāng)前所有與topic、partition以及broker有關(guān)的信息并進(jìn)行相應(yīng)的管理。對于所有topic
所對應(yīng)的Zookeeper中的/brokers/topics/[topic]節(jié)點添加PartitionModificationsListener，用來監(jiān)聽topic中的
分區(qū)分配變化。
4. 更新集群的元數(shù)據(jù)信息，同步到其他普通的broker節(jié)點中。
 

Partition副本選舉Leader機制

controller感知到分區(qū)leader所在的broker掛了(controller監(jiān)聽了很多zk節(jié)點可以感知到broker存活)，controller會從
ISR列表(參數(shù)unclean.leader.election.enable=false的前提下)里挑第一個broker作為leader(第一個broker最先放進(jìn)ISR
列表，可能是同步數(shù)據(jù)最多的副本)，如果參數(shù)unclean.leader.election.enable為true，代表在ISR列表里所有副本都掛
了的時候可以在ISR列表以外的副本中選leader，這種設(shè)置，可以提高可用性，但是選出的新leader有可能數(shù)據(jù)少很多。
副本進(jìn)入ISR列表有兩個條件：
1. 副本節(jié)點不能產(chǎn)生分區(qū)，必須能與zookeeper保持會話以及跟leader副本網(wǎng)絡(luò)連通
2. 副本能復(fù)制leader上的所有寫操作，并且不能落后太多。(與leader副本同步滯后的副本，是由
replica.lag.time.max.ms 配置決定的，超過這個時間都沒有跟leader同步過的一次的副本會被移出ISR列表)
 

消費者消費消息的offset記錄機制

每個consumer會定期將自己消費分區(qū)的offset提交給kafka內(nèi)部topic：__consumer_offsets，提交過去的時候，key是
consumerGroupId+topic+分區(qū)號，value就是當(dāng)前offset的值，kafka會定期清理topic里的消息，最后就保留最新的
那條數(shù)據(jù)
因為__consumer_offsets可能會接收高并發(fā)的請求，kafka默認(rèn)給其分配50個分區(qū)(可以通過
offsets.topic.num.partitions設(shè)置)，這樣可以通過加機器的方式抗大并發(fā)。
 

消費者Rebalance機制

rebalance就是說如果消費組里的消費者數(shù)量有變化或消費的分區(qū)數(shù)有變化，kafka會重新分配消費者消費分區(qū)的關(guān)系。
比如consumer group中某個消費者掛了，此時會自動把分配給他的分區(qū)交給其他的消費者，如果他又重啟了，那么又會
把一些分區(qū)重新交還給他。
注意：rebalance只針對subscribe這種不指定分區(qū)消費的情況，如果通過assign這種消費方式指定了分區(qū)，kafka不會進(jìn)
行rebanlance。
如下情況可能會觸發(fā)消費者rebalance
1. 消費組里的consumer增加或減少了
2. 動態(tài)給topic增加了分區(qū)
3. 消費組訂閱了更多的topic
rebalance過程中，消費者無法從kafka消費消息，這對kafka的TPS會有影響，如果kafka集群內(nèi)節(jié)點較多，比如數(shù)百
個，那重平衡可能會耗時極多，所以應(yīng)盡量避免在系統(tǒng)高峰期的重平衡發(fā)生。
Rebalance過程如下
當(dāng)有消費者加入消費組時，消費者、消費組及組協(xié)調(diào)器之間會經(jīng)歷以下幾個階段