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

当一个故障副本被重启后，它首先从磁盘上恢复最新的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大好用实践

（编辑：惠州站长网）

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