一、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是什麼
首先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副本復活，雖然可以保證一致性，但可能需要很長時間。而如果選擇立即可用的副本，則很可能該副本並不一致。