Spring Cloud Kafka Binder配置transactionIdPrefix后消息重复发送问题

问题根因初步判断 #

你看到的b'\x00\x00\x00\x00\x06&'乱码消息不是业务代码生成的，是Kafka事务的控制标记消息，用于标记事务的提交/中止状态，默认read_uncommitted隔离级别的消费者会看到这类消息，而read_committed级别的消费者会自动过滤。你遇到的双消息、DLQ重复写入问题，核心是手动提交偏移量逻辑和Binder事务自动管理规则冲突导致的。

排查思路 #

• 验证乱码消息属性
  使用Kafka官方命令行消费者指定--isolation-level read_committed参数消费目标Topic，确认是否只能看到正常JSON业务消息。如果是，说明第二条消息是事务控制标记，排除代码重复发送业务消息的可能性。
• 排查手动ack与事务管理的冲突
  配置transactionIdPrefix后，Spring Cloud Kafka Binder会开启全局事务，消费偏移量提交、出站消息发送、DLQ消息发送都会纳入同一个事务统一管理，不需要手动调用ack方法，也不需要配置autoCommitOffset=false。你代码中手动执行ack会导致偏移量提前提交，事务管理器在事务结束时又会执行一次提交逻辑，触发重复的事务标记写入，同时异常场景下会导致DLQ被重复写入两次。
  验证方式：删除代码中所有ack.acknowledgement()调用，删除配置项spring.cloud.stream.kafka.bindings.input.consumer.autoCommitOffset=false，重启服务验证是否还有重复消息。
• 检查业务消费者隔离级别配置
  所有消费目标Topic的业务服务，都需要配置spring.cloud.stream.kafka.binder.consumer.configuration.isolation.level=read_committed，确保不会消费到事务控制消息。
• 验证DLQ重复问题
  修复手动ack冲突后，构造异常场景触发DLQ写入，确认DLQ是否还会出现两条消息。如果仍然重复，检查是否配置了重复的DLQ生产者实例，或者事务重试逻辑触发了重复写入。
• 排查版本兼容性问题
  如果你使用的Spring Cloud Stream版本低于3.1.x，存在已知的事务开启后控制消息被误判为业务消息的Bug，升级到最新稳定版即可解决。

事务场景最佳实践：所有偏移量提交、消息发送操作都交给Spring事务管理器统一处理，不要手动干预ack逻辑，避免事务状态不一致导致的各类异常。

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