Apache Kafka中Follower如何与Leader同步数据

重要名词解释： 

log end offset (logEndOffset)，表示log中最后的message的offst位置.
high watermark (HW)，表示Partition各个replicas数据间同步且一致的offset位置，即表示allreplicas已经commit位置，每个Broker缓存中维护此信息,并不断更新。

Kafka中replication复制数据

Kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。完全同步复制要求All Alive Follower都复制完，这条消息才会被认为commit，这种复制方式极大的影响了吞吐率。而异步复制方式下，Follower异步的从Leader复制数据，数据只要被Leader写入log就被认为已经commit，这种情况下如果Follower都复制完都落后于Leader，而如果Leader突然宕机，则会丢失数据。而Kafka的这种使用ISR的方式则很好的均衡了确保数据不丢失以及吞吐率。Follower可以批量的从Leader复制数据，而且Leader充分利用磁盘顺序读以及send file(zero copy)机制，这样极大的提高复制性能，内部批量写磁盘，大幅减少了Follower与Leader的消息量差。

优点

• 性能高，吞吐量大。
• 降低了系统和磁盘开销，Leader充分利用磁盘顺序读以及send file(zero copy)机制。
• 降低Leader与Follower之间网络开销和交互次数。

缺点

• 有可能会占用大量网络带宽(例如本来集群很大而且数据量很多，后来新增Broker节点需要迁移数据)，甚至堵塞网络，需要有流控机制，否则会影响线上服务。
• 因为Follower是批量拉取Leader消息，如果设置为保证所有replicas commit，才返回Ack给生产者会存在抖动现象，Follow拉取Leader修改HW，当HW与当次生产者请求logEndOffset的offst一致时，客户端等待时间会拉长。

kafka集群副本分布原理分析

Kafka中partition replication之间同步数据，从partition的leader复制数据到follower只需要一个线程(ReplicaFetcherThread)，实际上复制是follower(一个follower相当于consumer)主动从leader批量拉取消息的，这极大提高了吞吐量，从中可以看出无处不显示Kafka高吞吐量设计思想。

Kafka中partition replica复制机制：

Kafka中每个Broker启动时都会创建一个副本管理服务(ReplicaManager)，该服务负责维护ReplicaFetcherThread与其他Broker链路连接关系，该Broker中存在多少Follower的partitions对应leader partitions分布在不同的Broker上，有多少Broker就会创建相同数量的ReplicaFetcherThread线程同步对应partition数据，Kafka中partition间复制数据是由follower(扮演consumer角色)主动向leader获取消息，follower每次读取消息都会更新HW状态。每当Follower的partitions发生变更影响leader所在Broker变化时，ReplicaManager就会新建或销毁相应的ReplicaFetcherThread。
 

Kafka Broker中follower partition与ReplicaFetcherThread对应关系

partition三副本情况：

partition两副本情况：

Kafka中partitions数据一致性：

Kafka中Producer发送消息到Broker，Broker有三种返回方式，分别为noack、leader commit成功就ack、leader和follower同时commit成功才返回ack。第三种方式是数据强一致性。

如何保证数据强一致性？

当Producer发送消息到leader partition所在Broker时，首先保证leader commit消息成功，然后创建一个“生产者延迟请求任务”，并判断当前partiton的HW是否大于等于logEndOffset，如果满足条件即表示本次Producer请求partition replicas之间数据已经一致，立即向Producer返回Ack。否则待Follower批量拉取Leader的partition消息时，同时更新Leader ISR中HW，然后检查是否满足上述条件，如果满足向Producer返回Ack。