afka在所有broker中選出乙個controller，所有partition的leader選舉都由controller決定。controller會將leader的改變直接通過rpc的方式（比zookeeper queue的方式更高效）通知需為此作出響應的broker。同時controller也負責增刪topic以及replica的重新分配。
當有broker fari over controller的處理過程如下：
1.controller在zookeeper註冊watch，一旦有broker宕機（這是用宕機代表任何讓系統認為其die的情景，包括但不限於機器斷電，網路不可用，gc導致的stop the world，程序crash等），其在zookeeper對應的znode會自動被刪除，zookeeper會fire controller註冊的watch，controller讀取最新的倖存的broker
2.controller決定set_p，該集合包含了宕機的所有broker上的所有partition
3.對set_p中的每乙個partition
3.1 從/brokers/topics/[topic]/partitions/[partition]/state讀取該partition當前的isr
3.2 決定該partition的新leader。如果當前isr中有至少乙個replica還倖存，則選擇其中乙個作為新leader，新的isr則包含當前isr中所有倖存的replica（選舉演算法的實現類似於微軟的pacifica）。否則選擇該partition中任意乙個倖存的replica作為新的leader以及isr（該場景下可能會有潛在的資料丟失）。如果該partition的所有replica都宕機了，則將新的leader設定為-1。
3.3 將新的leader，isr和新的leader_epoch及controller_epoch寫入/brokers/topics/[topic]/partitions/[partition]/state。注意，該操作只有其version在3.1至3.3的過程中無變化時才會執行，否則跳轉到3.1
直接通過rpc向set_p相關的broker傳送leaderandisrrequest命令。controller可以在乙個rpc操作中傳送多個命令從而提高效率。
再平衡
建election.json檔案
,,
]}
/opt/cloudera/parcels/kafka/lib/kafka/bin/kafka-preferred-replica-election.sh --zookeeper zk1:2181 --path-to-json-file election.json/opt/cloudera/parcels/kafka/lib/kafka/bin/kafka-topics.sh --zookeeper zk1:2181 --topic topic_replica_test --describe
[一次因為kafka分割槽的leader不為優先副本導致的消費堆積問題的原因排查及問題解決方法(
kafka的leader選舉過程
zookeeper之leader選舉過程
關於leader選舉會分為兩個過程 1.啟動時leader的選舉 2.leader崩潰時的選舉 一在每個節點剛啟動的時候，狀態都是locking狀態，然後就會開始選舉的流程，因為leader選舉至少需要兩台伺服器，所以一般會選舉三颱組成伺服器集群。當第一台伺服器剛啟動的時候，它自己是無法進行和完成l...
副本的leader選舉
kafka提供了資料複製演算法保證，如果leader副本所在的broker節點宕機或者出現故障，或者分割槽的leader節點發生故障，這個時候怎麼處理呢？那麼，kafka必須要保證從follower副本中選擇乙個新的leader副本。那麼kafka是如何實現選舉的呢？要了解leader選舉，我們需要...
副本的leader選舉
kafka提供了資料複製演算法保證，如果leader副本所在的broker節點宕機或者出現故障，或者分割槽的leader節點發生故障，這個時候怎麼處理呢？那麼，kafka必須要保證從follower副本中選擇乙個新的leader副本。那麼kafka是如何實現選舉的呢？要了解leader選舉，我們需要...