Spring Kafka乱序提交模式下异常场景的行为咨询

首先明确核心结论：如果线程池内处理抛出异常导致记录从未被调用acknowledge()，Spring Kafka不会自动重放该消息，且会持续阻塞消费者拉取新消息，必须由开发者自行处理异常和重试逻辑。

具体表现 #

当启用乱序提交（通过ContainerProperties.setOutOfOrderCommit(true)或配置spring.kafka.listener.out-of-order-commit=true）时：

• 监听器容器会跟踪所有已消费但未确认的记录，暂停拉取新的消息，直到所有未确认记录都被acknowledge()。
• 若某条记录因异常从未触发确认，容器会一直处于等待状态，对应的偏移量永远不会提交，消费者也不会恢复拉取新消息，更不会自动重放这条未确认的消息。

原因 #

乱序提交模式下，Spring Kafka的设计逻辑是依赖开发者明确确认每条记录的处理结果：

• 文档明确禁止使用nack()，因此无法通过nack触发框架层面的重试或重放。
• 容器仅负责跟踪未确认的记录，不会主动判断记录是否处理失败，也没有内置的超时或重试机制来处理未确认的情况。

解决方案 #

针对这种场景，你需要在异步处理逻辑中主动处理异常：

1. 捕获异常并实现自定义重试
   在线程池的任务逻辑中捕获所有异常，对失败的消息进行重试（比如使用Spring Retry框架，或自定义重试次数），重试成功后再调用acknowledge()。
2. 死信队列（DLQ）处理
   若重试多次仍失败，将消息发送到死信队列进行后续人工处理，然后调用acknowledge()，避免阻塞容器继续消费其他消息。
3. 利用Kafka的max.poll.interval.ms兜底
   若未处理异常导致长时间未提交偏移量，当超过max.poll.interval.ms设置的时间后，Kafka Broker会判定该消费者失效，触发分区再均衡，此时该分区会被分配给其他消费者，未提交偏移量的消息会被重放。但这种方式属于兜底方案，会导致分区重新分配，影响消费稳定性，不推荐作为常规处理方式。

注意事项 #

• Acknowledgment对象是线程安全的，可以在异步线程中调用，但要注意不要丢失该对象的引用。
• 务必避免未捕获的异常导致acknowledge()未被调用，否则会持续阻塞消费者，影响整个消费链路的可用性。

内容的提问来源于stack exchange，提问作者Tobias Horst