我寫了另一篇zookeeper選舉機制的,可以參考:zookeeper 負載均衡 核心機制 包含ZAB協議(滴滴,阿里面試)
一、zookeeper 與kafka保持數據一致性的不同點:
(1)zookeeper使用了ZAB(Zookeeper Atomic Broadcast)協議,保證了leader,follower的一致性,leader 負責數據的讀寫,而follower只負責數據的讀,如果follower遇到寫操作,會提交到leader;
當leader宕機的話,使用 Fast Leader Election 快速選舉出新的leader,節點在一開始都處於選舉階段,只要有一個節點得到超半數節點的票數,它就可以當選准 leader。
其客戶端根據鏈接的follower不同,可能讀取到不同的數據。這是由於副本沒有完全同步,存在時間差的原因。由於follower分擔了讀取數據的壓力,zookeeper只要保留全局leader即可,不再進行細分。
如下所示:leader==》讀寫,follower==>只負責讀;
Zookeeper工作方式
》Zookeeper集群包含一個1個Leader,多個Follower
》所有的Follower都可提供讀服務
》所有的寫操作都會被forward到Leader
》Client與Server通過NIO通信
》全局串行化所有的寫操作
》保證同一客戶端的指令被FIFO執行
》保證消息通知的FIFO
(2)kafka 不同,只有leader 負責讀寫,follower只負責備份,如果leader宕機的話,Kafaka動態維護了一個同步狀態的副本的集合(a set of in-sync replicas),簡稱ISR,ISR中有f+1個節點,就可以允許在f個節點down掉的情況下不會丟失消息並正常提供服。ISR的成員是動態的,如果一個節點被淘汰了,當它重新達到“同步中”的狀態時,他可以重新加入ISR。因此如果leader宕了,直接從ISR中選擇一個follower就行。
kafka在引入Replication之后,同一個Partition可能會有多個Replica,而這時需要在這些Replication之間選出一個Leader,Producer和Consumer只與這個Leader交互,其它Replica作為Follower從Leader中復制數據。因為需要保證同一個Partition的多個Replica之間的數據一致性(其中一個宕機后其它Replica必須要能繼續服務並且即不能造成數據重復也不能造成數據丟失)。如果沒有一個Leader,所有Replica都可同時讀/寫數據,那就需要保證多個Replica之間互相(N×N條通路)同步數據,數據的一致性和有序性非常難保證,大大增加了Replication實現的復雜性,同時也增加了出現異常的幾率。而引入Leader后,只有Leader負責數據讀寫,Follower只向Leader順序Fetch數據(N條通路),系統更加簡單且高效。
Kafka:由於kafka的使用場景決定,其讀取數據時更關注數據的一致性
從leader讀取和寫入可以保證所有客戶端都得到相同的數據,否則可能存在一些在ISR中注冊的節點(replication-factor大於min.insync.replicas),因未來得及更新副本而無法提供的數據。相應的為了規避都從leader上讀取帶來的資源競爭,可以根據不同topic和不同partition設置不同的leader。
如下所示:leader==>負責讀寫,follower 負責同步,只負責備份
Zab協議-廣播模式
客戶端每發送一個更新請求,ZooKeeper都會生成一個全局唯一的遞增編號,這個編號反映了所有事務操作的先后順序,這個唯一編號就是事務ID(ZXID),只有更新請求才算是事務請求。
為保證按照事務的ZXID先后順序來處理,Leader服務器會分別為每個Follower服務器創建一個隊列,並將事務的先后順序放入隊列中,並按照FIFO的策略進行消息發送。收到需要處理的事務后,Follower服務器會首先以事務日志的形式寫入服務器的磁盤中,寫入成功后會向Leader服務器發送ACK響應。當Leader服務器收到超過一半的Follower服務器的ACK響應后,會向所有Follower服務器廣播Commit消息,收到Commit消息的Follower服務器也會完成對事務的提交。
如果接收到事務請求的是Follower服務器,它會將請求轉發給Leader服務器處理。
二、相同點:
在數據寫入過程中,leader與follower都具有相同的先后關系,即數據先寫入leader,而后按照一定的規則完成在follower上的最少副本數寫入,即可返回調用客戶端,該數據寫入成功過。
kafka的最少副本數量有min.insync.replicas控制;zookeeper的最少副本數是半數以上節點。
此處的設置都是優先保證可用性,而犧牲一定的數據一致性。
三、具體的Kafka的leader選舉機制如下:
Kafka的Leader是什么
其次為了保證高可用,每個分區都會有一定數量的副本(replica)。這樣如果有部分服務器不可用,副本所在的服務器就會接替上來,保證應用的持續性。

但是,為了保證較高的處理效率,消息的讀寫都是在固定的一個副本上完成。這個副本就是所謂的Leader,而其他副本則是Follower。而Follower則會定期地到Leader上同步數據。
Leader選舉
Kafka會在Zookeeper上針對每個Topic維護一個稱為ISR( in-sync replica,已同步的副本)的集合,該集合中是一些分區的副本。只有當這些副本都跟Leader中的副本同步了之后,kafka才會認為消息已提交,並反饋給消息的生產者。如果這個集合有增減,kafka會更新zookeeper上的記錄。
如果某個分區的Leader不可用,Kafka就會從ISR集合中選擇一個副本作為新的Leader。
顯然通過ISR,kafka需要的冗余度較低,可以容忍的失敗數比較高。假設某個topic有f+1個副本,kafka可以容忍f個服務器不可用。
為什么不用少數服從多數的方法
如果所有的ISR副本都失敗了怎么辦
如果要等待ISR副本復活,雖然可以保證一致性,但可能需要很長時間。而如果選擇立即可用的副本,則很可能該副本並不一致。
參考:kafka 基礎知識梳理