數據一致性 kafka 是保存副本 leader讀寫，follower 只備份 而 zookeeper是 leader 讀寫，follower負責讀

我寫了另外一篇zookeeper選舉機制的，能夠參考：zookeeper 負載均衡 核心機制 包含ZAB協議(滴滴，阿里面試)

1、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服務器處理。

2、相同點：

在數據寫入過程當中，leader與follower都具備相同的前後關係，即數據先寫入leader，然後按照必定的規則完成在follower上的最少副本數寫入，便可返回調用客戶端，該數據寫入成功過。
kafka的最少副本數量有min.insync.replicas控制；zookeeper的最少副本數是半數以上節點。
此處的設置都是優先保證可用性，而犧牲必定的數據一致性。

 

3、具體的Kafka的leader選舉機制以下：

Kafka的Leader是什麼

  首先Kafka會將接收到的消息分區（partition），每一個主題（topic）的消息有不一樣的分區。這樣一方面消息的存儲就不會受到單一服務器存儲空間大小的限制，另外一方面消息的處理也能夠在多個服務器上並行。
  其次爲了保證高可用，每一個分區都會有必定數量的副本（replica）。這樣若是有部分服務器不可用，副本所在的服務器就會接替上來，保證應用的持續性。

  可是，爲了保證較高的處理效率，消息的讀寫都是在固定的一個副本上完成。這個副本就是所謂的Leader，而其餘副本則是Follower。而Follower則會按期地到Leader上同步數據。

Leader選舉

  若是某個分區所在的服務器除了問題，不可用，kafka會從該分區的其餘的副本中選擇一個做爲新的Leader。以後全部的讀寫就會轉移到這個新的Leader上。如今的問題是應當選擇哪一個做爲新的Leader。顯然，只有那些跟Leader保持同步的Follower才應該被選做新的Leader。
  Kafka會在Zookeeper上針對每一個Topic維護一個稱爲ISR（ in-sync replica，已同步的副本）的集合，該集合中是一些分區的副本。只有當這些副本都跟Leader中的副本同步了以後，kafka纔會認爲消息已提交，並反饋給消息的生產者。若是這個集合有增減，kafka會更新zookeeper上的記錄。
  若是某個分區的Leader不可用，Kafka就會從ISR集合中選擇一個副本做爲新的Leader。
  顯然經過ISR，kafka須要的冗餘度較低，能夠容忍的失敗數比較高。假設某個topic有f+1個副本，kafka能夠容忍f個服務器不可用。

爲何不用少數服從多數的方法

  少數服從多數是一種比較常見的一致性 算法和Leader選舉法。它的含義是隻有超過半數的副本同步了，系統纔會認爲數據已同步；選擇Leader時也是從超過半數的同步的副本中選擇。這種算法須要較高的冗餘度。譬如只容許一臺機器失敗，須要有三個副本；而若是隻容忍兩臺機器失敗，則須要五個副本。而kafka的ISR集合方法，分別只須要兩個和三個副本。

若是全部的ISR副本都失敗了怎麼辦

  此時有兩種方法可選，一種是等待ISR集合中的副本復活，一種是選擇任何一個當即可用的副本，而這個副本不必定是在ISR集合中。這兩種方法各有利弊，實際生產中按需選擇。
  若是要等待ISR副本復活，雖然能夠保證一致性，但可能須要很長時間。而若是選擇當即可用的副本，則極可能該副本並不一致。

 

 

 

 

參考：kafka 基礎知識梳理

參考：kafka 學習 很是詳細的經典教程

參考：Kafka的Leader的選舉機制

參考：Kafka與Zookeeper

參考：zookeeper與kafka的選舉算法