Spring Kafka批量监听器应用重启场景下消息可靠性问题咨询

重启重复消费3条的根因 #

Batch ack模式的默认机制是整个批次的消息全部处理完成后，才会统一提交该批次的最大偏移量。从你提供的日志可以看到，offset为2797145的批次刚启动处理，进程就直接断开终止，没有完成偏移量提交。Kafka服务端未收到该批次的提交确认，应用重启后会重新推送该批次的3条消息，就出现了重复消费的情况。
对应的日志印证：

2021-09-21 22:37:22,448 INFO  [org.springframework.kafka.KafkaListenerEndpointContainer#0-0-C-1]  com.example.demo.kafka.CassandraConsumer:  processing batch size: 3, starting partition: 0, offset: 2797145
Disconnected from the target VM, address: '127.0.0.1:55506', transport: 'socket'

批量大小设为500且关闭前未完成持久化的问题 #

会出现两类核心问题：

• 重复消费范围放大：未提交偏移量的500条消息会在重启后全部被重新推送，若没有幂等处理，会产生500条重复脏数据，影响范围远大于小批量场景
• 持久化失败风险升高：如果应用优雅关闭的等待时长不足，Spring容器会提前销毁Hikari数据源等资源，导致正在执行的批量数据库写入直接失败，若业务逻辑没有失败重试机制，还会出现数据一致性问题；如果代码存在先提交偏移量再写库的错误逻辑，甚至会直接丢失500条消息

• 调整优雅关闭配置
  开启Spring Kafka容器的优雅关闭逻辑，设置spring.kafka.listener.stop-immediate=false，收到关闭信号后容器会停止拉取新消息，等待当前批次处理完成后再关闭；同时配置spring.lifecycle.timeout-per-shutdown-phase=60s（可根据单批次最大处理时长调整），给大批次足够的处理时间，避免资源提前被销毁。
• 事务绑定消费逻辑
  把批量持久化逻辑包裹在数据库事务中，只有整个批次全部写入数据库成功后，才提交Kafka偏移量；也可以直接使用Spring Kafka提供的消费事务能力，将数据库事务和偏移量提交做原子绑定，保证两者要么同时成功，要么同时回滚，避免中间状态。
• 新增消费幂等校验
  以Kafka消息的分区+偏移量作为唯一键，或者使用业务本身的唯一标识作为幂等键，入库前先校验该条消息是否已经被处理过，不管什么场景下的重复消费都不会产生脏数据，作为兜底方案。
• 合理设置批量参数
  不要盲目设置过大的批量大小，根据数据库的写入性能调整批量值，控制单批次的最大处理时长在10s以内，降低异常场景下的影响范围。

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