生产者消息丢失
2022-07-25 13:19:06 0 举报
kafka 生产者消息丢失
作者其他创作
大纲/内容
我们接受了之前的教训,现在把生产者的 acks 设为 all
X
acks=all首领在返回确认或错误响应之前,会等待所有同步副本都收到消息
丢
Leader
fail首领不可用
consumer
重试风险
消费
为 broker 配置了 3 个副本,并且禁用了不完全首领选举,这样应该可以保证万无一失。生产者发送一个消息给首领,首领成功写入,但跟随者副本还没有接收到这个消息。首领向生产者发送了一个响应,告诉它“消息写入成功”,然后它崩溃了,而此时消息还没有被其他副本复制过去。另外两个副本此时仍然被认为是同步的(毕竟判定一个副本不同步需要一小段时间),而且其中的一个副本成了新的首领。因为消息还没有被写入这个副本,所以就丢失了,但发送消息的客户端却认为消息已成功写入。因为消费者看不到丢失的消息,所以此时的系统仍然是一致的(因为副本没有收到这个消息,所以消息不算已提交),但从生产者角度来看,它丢失了一个消息。
follower
写入
acks=1首领在收到消息并把它写入到分区数据文件(不一定同步到磁盘上)时会返回确认或错误响应
acks=all
设置重试次数可以无限重试retries=MAX_INT
选举...
要注意,重试发送一个已经失败的消息会带来一些风险,如果两个消息都写入成功,会导致消息重复。例如,生产者因为网络问题没有收到 broker 的确认,但实际上消息已经写入成功,生产者会认为网络出现了临时故障,就重试发送该消息(因为它不知道消息已经写入成功)。在这种情况下,broker 会收到两个相同的消息。现实中的很多应用程序在消息里加入唯一标识符,用于检测重复消息,消费者在读取消息时可以对它们进行清理。还要一些应用程序可以做到消息的“幂等”,也就是说,即使出现了重复消息,也不会对处理结果的正确性造成负面影响。例如,消息“这个账号里有 110 美元”就是幂等的,因为即使多次发送这样的消息,产生的结果都是一样的。不过消息“往这个账号里增加 10 美元”就不是幂等的。
首领故障,正在选举..
produceracks=all
发送确认
produceracks=1
从上面两个例子可以看出,每个使用 Kafka的开发人员都要注意两件事情:1、根据可靠性需求配置恰当的 acks 值。2、在参数配置和代码里正确处理错误。
acks=1
不可重试错误
在此种模式下的运行速度是非常快的(这就是为什么很多基准测试都是基于这个模式),你可以得到惊人的吞吐量和带宽利用率,不过如果选择了这种模式,一定会丢失一些消息。
success
无效配置
最保险的做法同时也是最慢的做法
acks=0生产者只要能够通过网络把消息发送出去,那么就认为消息已成功写入
为 broker 配置了 3 个副本,并且禁用了不完全首领选举。我们接受了之前的教训,把生产者的 acks 设为 all。假设现在往 Kafka 发送消息,分区的首领刚好崩溃,新的首领正在选举当中,Kafka 会向生产者返回“首领不可用”的响应。在这个时候,如果生产者没能正确处理这个错误,也没有重试发送消息直到发送成功,那么消息也有可能丢失。这算不上是 broker 的可靠性问题,因为 broker 并没有收到这个消息。这也不是一致性问题,因为消费者并没有读到这个消息。问题在于如果生产者没能正确处理这些错误,弄丢消息的是它们自己。
acks=0
可重试错误
可能丢数据,即图1
重试
把生产者发送消息的 acks 设为 1(只要首领接收到消息就可以认为消息写入成功)
0 条评论
回复 删除
下一页