kafka是乙個高效能，高容錯，多副本，可複製的分布式訊息系統，是基於raft演算法來實現leader選舉的。整個架構設計中涉及幾處選舉：
所謂控制器就是乙個borker，在乙個kafka集群中，有多個broker節點，但是它們之間需要選舉出乙個leader，其他的broker充當follower角色。
集群中每選舉一次控制器，就會通過zookeeper建立乙個controller epoch，每乙個選舉都會建立乙個更大，包含最新資訊的epoch，如果有broker收到比這個epoch舊的資料，就會忽略它們，kafka也通過這個epoch來防止集群產生「腦裂」。
在kafka的集群中，會存在著多個主題topic，在每乙個topic中，又被劃分為多個partition，為了防止資料不丟失，每乙個partition又有多個副本，在整個集群中，總共有三種角色：
在kafka的消費端，會有乙個消費者協調器以及消費組，組協調器groupcoordinator需要為消費組內的消費者選舉出乙個消費組的leader，那麼如何選舉的呢？
private val members = new mutable.hashmap[string, membermetadata]leaderid = members.keys.headoption
// member是乙個hashmap的資料結構，key為消費者的member_id，value是元資料資訊，
// 那麼它會將leaderid選舉為hashmap中的第乙個鍵值對，它和隨機基本沒啥區別。
參考
Kafka的選舉機制
kafka架構裡有生產者，消費者和broker，第乙個啟動的broker會去zookeeper裡註冊，成為leader,而後面去zookeeper註冊的broker則會收到異常，只能註冊watch物件，對leader進行監控，如果leader broker掛了，其他第乙個註冊的broker成為新的l...
Kafka選舉機制及資料丟失情況分析
unclean.leader.election 只能在broker級別 實際上是在集群範圍內 進行配置，它的預設值是true 我們之前提到過，當分割槽首領不可用時，乙個同步副本會被選為新首領。如果在選舉過程中沒有丟失資料，也就是說提交的資料同時存在於所有的同步副本上，那麼這個選舉就是 完全 的。但如...
zookeeper選舉機制
fastleaderelection演算法通過非同步的通訊方式來收集其它節點的選票，同時在分析選票時又根據投票者的當前狀態來作不同的處理，以加快leader的選舉程序。每個在zookeeper伺服器啟動先讀取當前儲存在磁碟的資料,zookeeper中的每份資料都有乙個對應的id值,這個值是依次遞增的...