Java数据同步Kafka_Kafka 数据同步

复制原理

Kafka中Topic的每个Partition有一个预写式的日志文件，虽然Partition可以继续细分为若干个Segment File，但是对于上层应用来说可以将Partition看成最小的存储单元(一个含有多个Segment文件拼接的“巨型”文件)，每个Partition都由不可变的消息组成，这些消息被连续的追加到Partition中。

为了提高消息的可靠性，Kafka中每个Topic的partition有N个副本(replicas)，其中N(大于等于1)是Topic的复制因子(replica fator)个数。Kafka通过多副本机制实现故障自动转移。当Kafka集群中一个Broker失效情况下仍然保证服务可用。在Kafka中发生复制时确保Partition的日志能有序地写到其他节点上。当N个replicas中有一个为Leader，其他都为Follower，Leader处理Partition的所有读写请求，与此同时，Follower会被动定期地去复制Leader上的数据。

Kafka的复制原理如图所示。

ISR副本同步队列

如果Leader发生故障或挂掉，Kafka将从同步副本列表中选举一个副本为Leader，这个新Leader被选举出来并被接受客户端的消息成功写入。Leader负责维护和跟踪ISR(In-Sync Replicas的缩写，表示副本同步队列)中所有Follower滞后的状态。当Producer发送一条消息到Broker后，Leader写入消息并复制到所有Follower中。消息提交之后才被成功复制到所有的同步副本。消息复制延迟受最慢的Follower限制，对于那些“落后”太多或者失效的Follower，Leader将会把它从ISR中删除。

下面先介绍LEO和HW两个概念，如图所示。

• LEO：LogEndOffset的缩写，表示每个Partition的log文件中的最后一条消息的位置。

• HW是HighWatermark的缩写，是指Consumer能够看到的Partition消息的位置。

Consumer无法消费分区下Leader副本中(Follower)位移值大于分区HW的任何消息(即如上图中6~10部分消息)。这个涉及多副本的概念。

下面通过一个案例说明当Producer生产消息至Broker后，ISR、HW和LEO的流转过程。

(1)初始状态下，HW等于LEO，Follower将Leader中全部消息备份，此时有生产者向Kafka写入消息，如下图所示。

(2)生产者将消息写入Leader中，此时Leader将变更LEO的位置，Follower1和Follower2将对Leader中的新增消息进行备份，如下图所示。

(3)Follower1完成Leader中所有消息的备份，Follower2未完成备份，此时HW更新为4，如下图所示。

(4)所有的Follower都将Leader中的消息备份完成，如下图所示。