java - 卡夫卡 : what is the point of using "acknowledgment.nack" if I can simply "not acknowledgment.acknowledge"

Question

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

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

...

使用记录监听器，当调用 nack() 时，将提交任何未决的偏移量，丢弃上次轮询的剩余记录，并在其分区上执行搜索，以便在下一次轮询时重新传递失败的记录和未处理的记录( )。 消费者线程可以在重新交付前暂停 ，通过设置 sleep 参数。这与在容器配置了 SeekToCurrentErrorHandler 时引发异常的功能类似。
"

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

关于使用 nack 而不是根本不承认还有什么进一步的意义吗？

据我所知，该消息将在池中保存的时间比 nack sleep 长。因此，顺便说一句，如果消费者继续尝试获取消息并保存消息，假设问题在少于 sleep 时间的时间内得到解决，它将成功。

一个围绕点或优势将是生产者以某种方式收到使用 nack 的通知。如果是这样，我可以在某些特定情况下找到一些值(value)。假设使用 Log Compation(仅对最后一条消息状态感兴趣)或 Kafka 作为长期存储服务(我猜 future 的版本将提供这个 - KIP 405)

关于更一般的异常(exception)情况，我倾向于遵循 configure a SeekToCurrentErrorHandler and throw the exception 之类的方法。

Answer 1

nack只是使用 SeekToCurrentErrorHandler 的替代方法- 它是在我们制作 SeekToCurrentErrorHandler 之前添加的默认错误处理程序(以前，默认只是简单地记录错误)。

STCEH 更复杂，您可以配置重试次数，配置在重试结束后调用的恢复器(例如 DeadLetterPublishingRecoverer )。
nack不同于“不承认”；对于后者，如果您不抛出异常，您将从轮询中获取下一条记录(如果这是最后一条记录，则为下一条轮询)；除非您使用 nack，否则您将不会收到未确认记录的重新交付。或 STCEH 并引发异常。