领导层变更时的 Kafka 代理消息丢失场景

Question

我试图理解 Kafka 中消息丢失的以下行为。简而言之，当一个代理在早期死亡并且随后在一些消息处理之后，所有其他代理都会死亡。 如果首先死亡的经纪人启动，那么它在其他经纪人出现后不会赶上他们。 相反，所有其他代理都会报告错误并重置其偏移量以匹配第一个代理。 这种行为是否符合预期？需要进行哪些更改/设置才能确保零消息丢失？

卡夫卡版本：2.11-0.10.2.0

可重复的步骤

• 启动了1个zookeeper实例和3个kafka经纪人
• 创建了一个主题，复制因子为 3，分区为 3
• 将 kafka-console-consumer 附加到主题
• 使用 Kafka-console- Producer 生成 2 条消息
• 杀死了两名经纪人（1&2）
• 发送了两条消息
• 杀死最后剩下的经纪人（0）
• 调出没有看到最后两条消息的经纪人（1）
• 调出看到最后两条消息的经纪人 (2)，它显示错误

[2017-06-16 14:45:20,239] INFO Truncating log my-second-topic-1 to offset 1. (ka
fka.log.Log)
[2017-06-16 14:45:20,253] ERROR [ReplicaFetcherThread-0-1], Current offset 2 for
 partition [my-second-topic,1] out of range; reset offset to 1 (kafka.server.Rep
licaFetcherThread)

• 最后连接 kafka-console-consumer，它会看到两条消息，而不是发布的四条消息。

Answer 1

在此回复：https://kafka.apache.org/documentation/# Producerconfigs

生产者要求领导者在考虑请求完成之前收到的确认数量。这控制发送的记录的持久性。允许以下设置：

• acks=0 如果设置为零，那么生产者将根本不会等待服务器的任何确认。该记录将立即添加到套接字缓冲区并被视为已发送。在这种情况下，不能保证服务器已收到记录，并且重试配置不会生效（因为客户端通常不会知道任何失败）。每个记录返回的偏移量将始终设置为 -1。
• acks=1 这意味着领导者会将记录写入其本地日志，但会在不等待所有追随者完全确认的情况下做出响应。在这种情况下，如果领导者在确认记录后但在追随者复制它之前立即失败，那么记录将丢失。
• acks=all 这意味着领导者将等待完整的同步副本集确认记录。这保证了只要至少一个同步副本保持活动状态，记录就不会丢失。这是最强有力的保证。这相当于 acks=-1 设置。

默认 acks=1 因此将其设置为 'all' ：

acks=all

在你的 Producer.properties 文件中

Answer 2

检查 unclean.leader.election.enable 是否为 true，如果是，则将其设置为 false，以便只有同步的副本才能成为领导者。如果允许不同步的副本成为领导者，那么消息可能会被截断和丢失。

Answer 3

注意https://kafka.apache.org/documentation/# Producerconfigs 描述了一个 3.0.0 中的显着变化 默认情况下，生产者具有更强的交付保证：启用幂等性并将 ack 设置为 all 而不是 1。

因此，如果您使用的是 3.0+ 版本，则不再需要在生产者属性文件中将 ack 设置为 all。 默认设置。