数据一致性 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的选举算法