RocketMQ 的事务消息有什么缺点？你还了解过别的事务消息实现吗？

标签：消息队列、后端、RocketMQ

🏛 业务架构师

RocketMQ 事务消息的短板，我按真实运维体感列：

回查逻辑是业务负担：必须实现 checkLocalTransaction 且结论准确，回查以本地库为准——写得不对就是错账；且回查有时效上限，本地事务结果长时间未知时链路悬着；
只保证"发消息和本地事务"一致：消费端失败要靠重试 + 幂等 + 人工兜底另建一套；
排查链路长：半消息状态对排查者不直观，出问题要同时看 broker 与业务库；
吞吐受回查机制约束，不适合超高频写入场景。

其他实现我按投入产出排：

本地消息表：业务与消息同库同事务落表，定时任务扫描投递。逻辑直白、可查可补、没有额外中间件依赖——中小团队首选，代价是消息表与扫描任务的维护；
事务性 Outbox + CDC（Canal/Debezium）：binlog 变更直接转投 MQ，性能好且与业务解耦，但引入 CDC 链路，运维门槛上升；
Seata AT：对代码侵入低，但全局锁在高并发热点行上会排队，适合存量系统改造而非新建；
TCC：一致性强，但每个动作要写 Try/Confirm/Cancel 三套逻辑，开发成本翻倍，只留给资金类核心链路。

我的选型哲学：一致性方案的价格差异巨大，先问业务能容忍多久不一致、错一笔的代价多大，再定价。能用消息 + 对账兜底的，绝不一步到位上 TCC。

🏗 系统架构师

RocketMQ 事务消息的缺点：

只保证"生产者侧"的最终一致，且不保证实时——回查默认 60 秒一次，业务要容忍分钟级的不一致窗口；
回查逻辑要求生产者实现可查询的事务状态接口，对代码侵入大，且回查有次数上限（15 次），超限后消息废弃，需要人工或对账兜底；
不覆盖消费端：下游消费失败依旧要靠重试 + 死信 + 幂等闭环；
高并发下回查风暴会打到 DB（回查都去查库）。

其他实现方案：

本地消息表：本地事务里同时写业务表和消息表（同一事务强一致），后台任务扫表投递、投递成功标记。实现朴素、可观测性最好，是我的默认选择，代价是多一次扫表和业务表耦合；
事务性 outbox + CDC：用 Canal/Debezium 监听 binlog 变更发消息，业务零侵入，多一套 CDC 链路运维；
Kafka 事务：只覆盖 Kafka 内部，适合纯流处理管道；
Seata AT/TCC：跨多库多服务的分布式事务框架，重量级，适合强一致要求高的核心链路。

选型思路：一致性窗口容忍度 + 团队运维能力 + 是否跨外部系统，三者决定方案，没有银弹。

💻 全栈开发专家

RocketMQ 事务消息的缺点：

侵入性大：要写本地事务执行和回查两段逻辑，回查必须幂等、能查到可靠状态（一般要专门的事务日志表）。
只是最终一致，消息投递和下游消费之间仍有窗口；回查有次数上限（默认 15 次），超时半消息被删，极端场景下仍需对账兜底。
不支持延迟/批量消息组合，系统耦合特定 MQ，事务链路排查难度高（要追 half 消息状态）。

我知道的其他实现：

本地消息表（我最常用，最稳）：业务和"待发送消息记录"在同一个本地事务落库，后台任务扫描表发 MQ，发送成功标记，失败重试 + 对账。优点是无 MQ 特性依赖、可靠可审计；代价是业务表多一张表和定时任务。
Kafka 事务：只保证 Kafka 内部 exactly-once，覆盖不了外部系统，适用流计算场景。
Seata AT/TCC：强一致方案，但全局锁有性能代价，适合对一致性要求极高的资金场景。
最大努力通知：配合重试 + 对账，用于通知类（支付回调）。

选型话术：默认本地消息表（简单可靠），MQ 原生事务消息做锦上添花，资金强一致再上 Seata。