個人總結，請以官網為準kafka leader 選舉分為三種如有錯誤，歡迎指出
broker
乙個broker即可以理解為一台機器，broker主要負責監控管理分割槽和副本的狀態。在分割槽與副本的狀態發生變化時，做出對應的操作。比如：分割槽的leader副本出現了故障，那麼broker需要進行leader 副本的選舉。broker中的leader broker 稱為controller控制器。
選舉過程
broker們會向zookeeper進行節點/controller的建立，誰先建立成功，誰就是leader.並將自己的brokerid寫入節點的值中。如果其他的broker發現節點的值不為-1，則放棄選舉成為follower.
防止腦裂:
當舊的leader重生後，集群中的新的leader已經存在了，這時zookeeper就不知道聽誰的話了。
這就出現乙個集群有兩個大腦的情況了，即腦裂。
broker在建立控制器節點的時候，還會建立乙個/controller epoch，每當新的節點成為控制器，那麼就自動加一。這樣就防止舊的leader影響，如果它給zookeeper的值小於zookeeper 中epoch的值，直接拒絕它成為leader
controller具體區別於其他節點的工作
責任越大，能力越大。所以來看看，controller需要一些什麼額外工作
controller需要監聽zookeeper上資料變化，並同步給其他的節點，這些資料大概是：分割槽數變化，新的leader副本等之類。
在整個kafka的執行過程中一定會涉及到各種各樣的的事件的產生然後觸發節點間的通訊。這個過程，通過乙個linkblockquene,然後使用乙個專有的執行緒去處理。避免使用鎖機制降低效率
如圖：
在早期版本中，並沒有controller這個中間商，所有的節點都需要去訂閱zookeeper的事件，如果加分割槽了，一定要驚動所有人的事件，卻要驚動所有節點。這就造成了羊群效應
分割槽副本leader選舉
那些情況會觸發：
總的來說，從ar中選取第乙個存活的節點分割槽，並且它在isr中的。
為什麼是ar,不是isr
ar在不發生分割槽重分配的情況下，一般分割槽的順序是不變的，而isr會由於資料同步延遲的問題，一直在變化。
優先副本解決leader分配不均衡的問題
在整個kafka的長期執行中，會存在leader副本的選舉，掛掉，然後重新選舉的情況。kafka是不支援讀寫分離的，那麼只有leader副本在處理讀寫，那麼如果在這個過程**現了，多個分割槽的副本leader到了同一臺broker上，那麼分割槽的負載均衡的意義就失去了。所以kafka，引入優先副本的概念。
優先副本即為ar的第乙個副本，auto.leader.rebalance.enble開啟的情況下，controller會啟動定時任務進行優先副本的均衡，但是在生產環境中建議關閉。這樣減少這個過程的對消費者的影響。
通過kafka自帶的乙個指令碼完成，列如：
首先看到這個topic的分割槽1，2的副本leader都在 0 這台broker上，通過執行下面這個指令碼我們再看分割槽情況，它就會預設為每乙個分割槽的ar副本中第乙個。
我思考過乙個問題，這樣就一定能負載均衡嗎？
我沒有得到明確的答案，只是看到書裡寫這樣一句話：kafka會保證副本的盡量均勻的分布，並且同乙個分割槽的兩個副本一定不會出現在同乙個broker上。
所以基於上面的原因，再使用以上的分割槽機制是可以做到分割槽的負載均衡的，注意：是分割槽的負載均衡，不是資料的，如果你的資料分布的不均勻的話，消費者端也是不能負載均衡的。
注意：在節點掛掉後，節點上的副本資料是不會自動同步到其他節點的，這需要我們自己通過kafka自帶的指令碼，kafka-reassign-partition.sh去完成。
消費組 leader 選舉
基本上就是隨機了，就是這麼的任性與隨意。原始碼中是這樣的從乙個hash列表中取乙個消費者作為leader。
我們知道hash是沒有順序的，那麼就是隨機了
leader的選舉是因為某乙個消費者leader下線了，這時候就出現同一組中消費者數量的變化。這就不得不提到消費組的再均衡。由於一些原因，分割槽沒有人消費了，那麼就需要將它們分配給新的消費者或者存活下來的消費，否則業務邏輯就會出現漏數的情況了。這個再均衡的過程會引起stop the world的情況，所有的消費者都不能消費了。這是很可怕的情況，所有避免發生或者避免發生的時段。
什麼情況下會發生？
同一組中消費者數量的變化，有進有出
主題的分割槽數的變化，加減分割槽
組協調者節點的下線更換
分割槽的分配策略
rangeassignor:
partition size%consumer size=n,那麼前n個消費者分配到m+1，其他消費者分配到m個。
roundrobinassignor（輪詢）：
將消費組內部的所有消費者和所有主題的分割槽按字典順序排序，然後將分割槽依次分給消費者。
如下圖t0表示topic0,p1表示partition 1：
stickyassignor
在初始的情況下，他與輪詢策略的結果是一樣，但是當出現重新分配的時候。它會在盡可能保證分割槽不變化位置的情況，保證分割槽的均衡。
首先第乙個問題，主從讀寫解決了什麼問題。
解決了節點壓力的問題，主節點寫資料，從節點讀資料。但是kafka利用partition的方式，已經做到將同乙個topic的資料分散來節點的壓力。
然後主從讀寫帶來了什麼問題
主從的模式帶來的資料的延遲，從節點總是會落後主節點資料ms級別，甚至秒級別。但是在kafka除了在傳統的程式中做削峰，非同步的中介軟體外。它還是流式程式中中介軟體，比如flink,sparkstreaming,spark的實時性其實不高，它是一批次一批次處理，減少批次之間的間隔來完成假的實時的功能。但是flink就真的是實時，來一條幹一條。那麼在實時性高的場景中，如果出現秒級別甚至由於網路的原因，出現了分割槽級別的延遲，在實時程式中是不允許的。
訊息從生產者寫入kafka,首先寫入副本leader,然後副本同步leader的訊息。（訊息確認機制）
然後在同步訊息落後的副本會被踢出isr.
所以isr的概念是，能追趕的上leader的所有副本。
那些情況會落後於leader
怎麼判斷副本落後了
replica.lag.time.max.ms 引數：如果副本落後超過這個時間就判定為落後了，直到它回來
訊息複製分為非同步和同步（這就與ack的配置有關），isr是一直動態有進出的
zookeeper的leader選舉機制
三個核心選舉原則 1.zookeeper集群中只有超過了半數以上的伺服器啟動，此集群才能正常工作 2.在集群正常工作之前，myid小的伺服器會給myid大的伺服器投票，這種投票會一直持續到集群開始正常工作，即，選出了leader。3.選出leader之後，之前的伺服器們的狀態要由looking轉為f...
副本的leader選舉
kafka提供了資料複製演算法保證，如果leader副本所在的broker節點宕機或者出現故障，或者分割槽的leader節點發生故障，這個時候怎麼處理呢？那麼，kafka必須要保證從follower副本中選擇乙個新的leader副本。那麼kafka是如何實現選舉的呢？要了解leader選舉，我們需要...
副本的leader選舉
kafka提供了資料複製演算法保證，如果leader副本所在的broker節點宕機或者出現故障，或者分割槽的leader節點發生故障，這個時候怎麼處理呢？那麼，kafka必須要保證從follower副本中選擇乙個新的leader副本。那麼kafka是如何實現選舉的呢？要了解leader選舉，我們需要...