@KafkaListener使用Acknowledgment.nack()时消息跳过问题咨询

Spring Kafka version - 2.8.5
监听器代码实现：

@KafkaListener
void consumeMessages(@Payload List<String> messages, Ack ack) {
    // 业务逻辑：将消息放到独立线程中处理，处理完成后手动ack
    // 异常逻辑：线程资源不足时，等待2秒后调用nack
}

预期现象：调用nack的消息会在2秒后被监听器重新消费。
实际现象：被nack的消息直接被跳过，不会被监听器再次处理，只有重启Spring Boot应用后，这部分消息才会被重新拉取消费。

问题本质是手动Ack模式下，Ack对象的操作脱离了监听器容器的管理上下文，具体触发逻辑：

• 当你在监听方法内把消息提交到自定义独立线程处理后，监听方法会立刻返回。Spring Kafka监听容器默认会把「方法执行返回」作为单批次消息处理完成的标记，会直接在内存中更新当前分区的消费偏移量位置，准备拉取下一批消息。
• Ack.nack(sleep)方法的生效前提是：必须在监听方法的调用线程中、方法返回前执行。nack的底层逻辑是通知容器回滚当前批次的偏移量、等待指定时间后重新seek到nack标记的位置重新拉取。如果你在异步线程中延后调用nack，此时容器已经退出了当前批次的处理上下文，根本不会响应nack的回滚请求，内存中记录的消费偏移量已经走到了下一批消息的位置，自然不会再重新消费这批被nack的消息。
• 之所以重启后消息能被重新消费，是因为内存中更新的偏移量还没来得及同步提交到Kafka Broker，重启后消费者会从Broker上记录的最后一次提交的偏移量开始重新拉取，这部分没被正确提交的消息才会再次出现。
• 2.8.5版本没有对异步线程中操作Ack对象的场景做校验和异常提示，属于静默失败，很容易误导开发者以为消息丢失。

另外补充一个常见连带坑：批量监听模式下调用nack如果传错了index参数（比如要整批重投递却传了大于0的下标），也会导致index之前的消息被直接标记为已消费，出现部分消息跳过的现象。

根据业务场景选择对应方案即可：

• 方案1（优先选择）：不要在@KafkaListener方法内自定义线程池异步处理消息。消息消费、ack/nack操作全部在监听器的调用线程内同步执行，保证nack操作在方法返回前触发。如果需要提升消费并发，直接通过ConcurrentKafkaListenerContainerFactory配置消费者线程数即可，不需要在业务层手动开线程。
• 方案2：如果业务必须异步处理消息，放弃手动操作Ack对象的模式。将线程资源不足的场景封装为业务异常抛出，配合容器配置的SeekToCurrentBatchErrorHandler实现重试：指定异常抛出后等待2秒，自动seek回当前批次的起始位置重新消费，所有重试逻辑由容器托管，避免手动操作Ack脱离上下文的问题。
• 方案3：如果必须保留手动异步Ack的逻辑，需要做两个配置调整：一是将容器的ackMode设置为MANUAL，禁止容器在方法返回时自动推进偏移量；二是在把消息提交到异步线程前，先通过Ack对象打标挂起当前批次的提交流程，等异步线程中所有消息处理完成、执行完对应的ack/nack操作后，再通知容器继续推进偏移量。这种方案需要自己做好异步线程的异常兜底，避免出现消费偏移量卡死的问题。
• 配置校验：确认监听器容器没有开启enable.auto.commit自动提交配置，自动提交模式下偏移量会按定时任务强制同步到Broker，不管你有没有调用nack都可能出现消息跳过的问题。

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