我试图理解Kafka的以下信息丢失行为。简单地说，当一个代理在消息处理的早期和之后死亡时，所有其他代理都会死亡。如果死去的经纪商先创业，那么在其他经纪商出现之后，它就不会赶上他们。相反，所有其他代理都报告错误并重置其偏移量以匹配第一个代理。这种行为是预期的吗？有哪些更改/设置可以确保零消息丢失？
Kafka版本：2.11-0.10.2.0
可重复的步骤
启动了1个zookeeper示例和3个kafka代理
创建了一个主题，复制因子为3，分区为3
附加了一个Kafka控制台消费者的主题
使用kafka控制台生成器生成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控制台消费者，它会看到两条消息，而不是发布的四条消息。
2条答案
按热度按时间iszxjhcz1#
回复如下：https://kafka.apache.org/documentation/#producerconfigs
在考虑请求完成之前，制作人要求领队收到的确认数。这将控制发送的记录的持久性。允许以下设置：
acks=0如果设置为0，则生产者将根本不等待来自服务器的任何确认。记录将立即添加到套接字缓冲区并被视为已发送。在这种情况下，无法保证服务器已收到记录，重试配置将不会生效（因为客户端通常不知道任何失败）。为每条记录返回的偏移量将始终设置为-1。
acks=1这意味着领导者会将记录写入本地日志，但不会等待所有追随者的完全确认。在这种情况下，如果领导者在确认记录之后但在追随者复制它之前立即失败，那么记录将丢失。
acks=所有这一切意味着领导者将等待全套同步副本确认记录。这保证了只要至少有一个同步副本保持活动状态，记录就不会丢失。这是最有力的保证。这相当于acks=-1设置。
默认情况下，acks=1，因此将其设置为“all”：
acks=all在producer.properties文件中e37o9pze2#
检查unclean.leader.election.enable=true，如果是，则将其设置为false，以便只有不同步的副本才能成为leader。如果允许不同步的复制副本成为前导，则消息可能会被截断并丢失。