卡夫卡：如果我可以简单地“不确认.确认”，那么使用“acknowledgment.nack”有什么意义

Question

根据/spring-kafka/docs/2.4.4.RELEASE/，关于Kafka的新特性旨在否定确认，现在由Spring-Kafka支持

"... 从 2.3 版本开始，Acknowledgment 接口有两个额外的方法 nack(long sleep) 和 nack(int index, long sleep)。第一个用于记录侦听器，第二个用于批处理侦听器。调用您的侦听器类型的错误方法将引发 IllegalStateException。

...

使用记录侦听器，当调用 nack() 时，将提交任何挂起的偏移量，丢弃上次轮询的剩余记录，并在其分区上执行查找，以便在下一次轮询时重新发送失败的记录和未处理的记录（ ）。通过设置 sleep 参数，可以在重新传递之前暂停使用者线程。这与在容器配置有 SeekToCurrentErrorHandler 时抛出异常的功能类似。”

好吧，如果消费者方面发生了一些错误，比如说无法保存在数据库上，假设消费者没有acknowledge.acknowledge()，据我所知，消息仍在轮询中，它将再次被读取/使用。我想有人可以说，使用 nack(..., some time) 消费者可以睡觉，让有机会稍后再次阅读/消费并且不会遇到错误。如果继续听这个话题不是问题，我的直接问题是：

使用 nack 而不是简单地不承认还有什么意义吗？

据我所知，无论如何，该消息将在池中保留的时间长于 nack sleep 的时间。因此，顺便说一下，如果消费者不断尝试获取消息并保存消息，假设问题在睡眠时间内得到解决，它就会成功。

一个周围的点或优势是，以某种方式生产者得到通知使用 nack。如果是这样，我可以在某些特定场景中找到一些价值。假设使用 Log Compation（仅对最后一条消息状态感兴趣）或 Kafka 作为长期存储服务（我猜未来版本将提供此服务 - KIP 405）

关于更一般的异常，我倾向于遵循配置 SeekToCurrentErrorHandler 并抛出异常的方法

Answer 1

nack只是使用 a 的替代方法SeekToCurrentErrorHandler- 它是在我们创建SeekToCurrentErrorHandler默认错误处理程序之前添加的（以前，默认值只是记录错误）。

STCEH 更复杂，因为您可以配置重试次数，配置重试用完后调用的恢复器（例如DeadLetterPublishingRecoverer）。

nack与“不承认”不同；对于后者，如果您不抛出异常，您将从投票中获得下一条记录（如果这是最后一条记录，则为下一次投票）；除非您使用nack或 STCEH 并抛出异常，否则您将不会重新发送未确认的记录。