结论：用 spring-cloud-starter-stream-rocketmq + trans 类型生产者 + transactionlistener 可实现 rocketmq 事务消息，保障最终一致性；它不保证强一致，但避免消息与本地事务状态错位。
直接说结论：用 spring-cloud-starter-stream-rocketmq + Trans 类型生产者 + 实现 TransactionListener，就能在 Spring Cloud Stream 编程模型下跑通 RocketMQ 事务消息，达成最终一致性。它不保证强一致，但能规避“消息发了但本地事务失败”或“本地事务成功但消息没发出去”的典型断层。
为什么不能直接 send + @Transactional 套用？
这是最常踩的坑。很多人以为给业务方法加 @Transactional，再在方法里调用 MessageChannel.send() 就万事大吉——实际完全不可靠：
- 数据库事务提交和 MQ 网络发送是两个独立动作，中间存在时间窗口，网络抖动、超时、响应丢包都会导致状态错位
- Spring 的
@Transactional只管数据源，不管 RocketMQ 客户端连接、半消息写入、回查响应这些底层协议行为 - 没有回查机制兜底，一旦生产者进程崩溃或机器宕机，pending 状态的半消息就卡死在 Broker 上，既不投递也不清理
必须配置的三个核心项
缺一不可，漏掉任意一个都会退化为普通消息，失去事务语义：
-
producerType: Trans：必须显式设为Trans（不是Normal或默认值），否则 Binder 不会启用事务流程 -
transactionListener：必须指定一个实现了RocketMQLocalTransactionListener接口的 Bean，它承担本地事务执行 + 回查双重职责 -
group：生产者组名必须全局唯一且稳定，RocketMQ 回查请求是按 group 找到集群中任一存活实例发起的，组名乱变会导致回查失联
示例配置片段：
spring:
cloud:
stream:
bindings:
buy-out-0:
producer:
producerType: Trans
transactionListener: inventoryDeductTransactionListener
rocketmq:
binder:
name-server: 127.0.0.1:9876
group: order-producer-group
TransactionListener 里怎么写才不出错？
这个接口只有两个方法：executeLocalTransaction 和 checkLocalTransaction，但逻辑耦合紧密，容易写反：
-
executeLocalTransaction必须在方法体内完成全部本地操作（如扣库存、改订单状态），并返回明确状态：LocalTransactionState.COMMIT_MESSAGE、ROLLBACK_MESSAGE或UNKNOW；不能只抛异常，也不能依赖外层事务回滚来控制结果 -
checkLocalTransaction是回查入口，参数是原始半消息的msg，必须从中提取业务主键（比如订单号），再查 DB 确认该笔业务是否已成功落库；严禁在此方法里执行新增写操作，它只读不写 - 两次查询必须用同一套数据源和隔离级别，避免因 MVCC 或缓存导致判断不一致；建议对关键字段加
SELECT ... FOR UPDATE锁行
消费者端别指望“自动重试到成功”
事务消息只管“发”和“本地事务”的一致性，不管“消费成功”。RocketMQ 默认最多重试 16 次（可配），但失败后进死信队列是常态，尤其涉及外部 HTTP 调用、第三方 SDK 等不可控环节时：
- 不要在消费者里写 try-catch 吞掉所有异常，否则死信队列收不到失败消息，问题被静默掩盖
- 消费逻辑必须幂等，因为重试必然发生；推荐用 DB 唯一键、Redis SETNX 或状态机流转来拦截重复处理
- 死信消息不能丢，要接入监控告警（比如监听
%DLQ%xxxtopic），人工介入或走补偿 Job 处理，这才是最终一致性的最后一环
真正难的从来不是把事务消息跑起来，而是设计出能扛住回查延迟、死信堆积、跨服务幂等这三重压力的业务闭环。很多项目卡在这一步，不是代码不会写，是业务状态分支没想全。
