Spring Kafka 2.8手动提交模式变更及2.7版异步ack安全性咨询

1. MANUAL模式与asyncAcks参数的逻辑区别 #

你对MANUAL模式的基础理解是正确的，它和新增的asyncAcks参数控制的是两个完全不同维度的逻辑：

• MANUAL/MANUAL_IMMEDIATE控制的是提交触发时机：
  • MANUAL模式下，你调用acknowledge()只是标记该消息已处理，不会立刻触发offset提交，要等到当前消费批次的所有消息都被标记确认后，才会统一执行提交动作，语义和BATCH模式完全一致。
  • MANUAL_IMMEDIATE模式下，你调用acknowledge()会立刻触发提交动作，不需要等批次处理完。
• 2.8新增的asyncAcks参数控制的是提交动作本身的执行方式：
  • 默认值true：触发提交动作时，调用消费者的commitAsync方法异步提交，提交请求发送后立刻返回，不会阻塞消费者线程拉取新消息，提交结果通过回调处理，失败时会触发错误日志或自定义异常处理器。
  • 设为false：触发提交动作时，调用消费者的commitSync方法同步提交，会阻塞消费者线程，直到broker返回提交成功响应、或提交超时抛出异常，才会继续后续消费逻辑。

2. Spring Kafka 2.7版本异步发送后ack的安全性 #

这个方案是不安全的，原因如下：
Spring Kafka 2.7版本确实不支持乱序ack，容器内部是按offset从小到大的顺序跟踪确认状态，仅会提交最大的连续已确认offset。而kafkaTemplate.send返回的ListenableFuture的完成顺序是不确定的，很可能出现offset更大的后消费消息先发送完成、先执行ack，此时容器会误认为前面所有offset都已处理完成，直接提交这个大offset。如果此时offset更小的先消费消息发送失败，就没有重试机会，直接造成消息丢失。

2.7版本的替代实现方案 #

如果必须实现「发送成功才提交offset」的语义，推荐选择以下两种方案：

• 同步发送：直接调用kafkaTemplate.send(...).get()同步等待发送结果，发送成功后直接在监听器主线程调用ack，发送失败则抛出异常触发重试或进入死信队列，该方案实现简单，ack顺序和消费顺序一致，不会出现乱序问题。
• 自定义状态跟踪：如果需要异步发送提升性能，可以自己维护当前批次所有消息的offset和发送状态，等当前批次所有消息都发送成功后，再按offset顺序完成确认，或直接手动提交当前批次最大的offset，该方案性能更高，但需要自行处理发送失败、状态清零等边界逻辑，实现复杂度较高。

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