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

当一个故障副本被重启后，它首先从磁盘上恢复最新的HW，并将日志截断到HW。这是必要的，因为不能保证在HW之后的消息被提交，所以可能需要丢弃。然后副本成为follower，并继续从leader那里获取HW以后的消息。一旦完全赶上leader，这个副本从新被加入到ISR中。系统将重新回到fully replicated模式。

故障处理

kafka依赖zookeeper检测broker故障，kafka会用一个controller(broker集合中的一个)接收所有zookeeper关于故障，选举新leader等相关通知，这样还有一个好处，减少了对zookeeper的压力。如果某个leader故障，controller就会从ISR副本中选举一个新的leader，并发布新leader的消息给其他follower。

按照设计，leader选举过程中，已经提交的消息总是会被保留，一些未提交的消息可能会丢失。leader和每个分区的ISR也会被保存在Zookeeper中，controller出现故障转移时需要用到。由于broker级别的故障一般会非常少，所以预期的leader和ISR都会不经常改变。

对客户端来说，broker仅向消费者公开已经提交的消息。broker故障期间，已提交的数据始终被保留。消费者使用相同的offset可以从另一个被选举为leader的副本拉取消息。

生产者能选择在broker收到消息后何时得到broker的确认。例如，它能等到消息被leader提交并被所有ISR确认(即acks=-1)。另外，也可以选择消息只要被leader追加到日志中，可能还没有提交(acks=0表示无需等待leader确认，acks=1表示需要等待leader确认)。前一种情况即acks=-1，生产者需要等待更长的时间。但是确认的消息都保证在broker中保留。后一种情况即acks=0或者1，生产者有更低的延迟，更高的吞吐量，但一些确认的消息在broker故障时可能会丢失。如何抉择，由你决定。

【编辑推荐】

1. 批处理ETL已死，Kafka才是数据处理的未来？
2. Kafka的存储机制以及可靠性
3. Kafka Connect如何实现同步RDS binlog数据?
4. Kafka解惑之时间轮 (TimingWheel)
5. 使用Scala开发Apache Kafka的TOP 20大好用实践

（编辑：开发网_郴州站长网）

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