Kafka集群内复制功能深入剖析

为了发布消息到分区，客户端首先从zookeeper中找到分区的leader，然后发送消息到这个leader。leader写消息到它的本地日志，每个follower经常从leader拉取最新的消息。所以，follower接收到的所有消息的顺序和leader保持一致，follower把每条接收到的消息写入它的本地日志，并向leader发送一个确认。一旦leader接收到所有ISR副本的确认，消息就能被提交。leader推进HW，然后向客户端发送确认。为了更好的性能，每个follower在把消息写入内存后，就发送确认。因此，对于每条提交的消息，我们保证它被保存到多个副本的内容中然而，不保证任何副本已经持久化已提交消息到磁盘上。

由于这种相关故障相对罕见，并且这种方法能给我们一个在响应时间和持久性之间一个很好的平衡。在将来，kafka可能考虑增加一个选项参数从而提供更强的保证。

读

为了简化，读也是leader提供服务，并且只有HW以上的消息才会被暴露给消费者读取。

异步复制

为了支持异步复制，leader可以在消息写入本地日志后，马上通知客户端。唯一需要注意的是在追赶阶段，follower必须截断HW位置以后的数据。follower主要是异步复制，所以不能保证提交的消息在broker故障后不丢失。

复制实现

kafka复制示意图如下所示：

• 集群总计4个broker(broker1~broker4);
• 1个topic，2个分区，3个副本;
• 分区1即topic1-part1的leader在broker1上，分区2即topic1-part2的leader在broker4上;

producer写入消息到分区topic1-part1的leader上(在broker1上)，然后复制到它的两个副本，分别在broker2和broker3上。

producer写入消息到分区topic1-part2的leader上(在broker4上)，然后复制到它的两个副本，分别在broker2和broker3上。

当生产者发布消息到topic的某个分区时，消息首先被传递到leader副本，并追加日志。follower副本从leader中不停的拉取新消息，一旦有足够的副本收到消息，leader就会提交这个消息。

这里有个问题，leader是怎么决定什么是足够的。kafka维护了一个 in-sync replica(ISR)集合。这个ISR副本集都是存活的，并且完全赶上leader的副本，没有消息延迟(leader总是在ISR集合中)。当分区初始化创建时，每个副本都在ISR集合中。当新消息发布后，leader提交消息前一直等待直到所有ISR副本收到消息。如果某个follower副本故障，它将会被从ISR中移除。leader会继续提交新的消息，只不过ISR数量相比分区创建时副本数量更少。

请注意，现在，系统运行在under replicated模式。

leader还会维护high watermark (HW，可以翻译成高水位)，是指分区中最后一次提交消息的offset。HW会被不断传播给follower副本：

kafka high watermark

（编辑：惠州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!