事务消息和本地消息表到底怎么选？一次讲清适用场景、一致性差异与工程取舍
大家好，我是一名有 4 年工作经验的 Java 后端开发。
做分布式一致性时，很多人都会遇到一个经典问题：事务消息和本地消息表，到底该选哪个？
这篇文章我想系统聊一聊，这两种方案分别适合什么场景、各自的优缺点是什么，以及工程上怎么做取舍。
🦅个人主页
🐼
文章目录
- 事务消息和本地消息表到底怎么选？一次讲清适用场景、一致性差异与工程取舍
- 一、为什么会有这个问题
- 二、事务消息解决什么
- 三、本地消息表解决什么
- 四、怎么选更合理
- 4.1 如果团队更偏业务可控、想要稳定落地
- 4.2 如果链路特别关键，且 MQ 团队能力成熟
- 4.3 如果只是想先把问题解决掉
- 五、最容易踩的坑
- 5.1 以为事务消息就不用幂等
- 5.2 以为本地消息表就等于强一致
- 5.3 只做方案，不做补偿和监控
- 六、面试中怎么回答
- 七、总结
- 八、结尾
一、为什么会有这个问题
因为很多业务都会遇到同一个场景：
- 本地事务改数据库
- 同时还要发 MQ
比如：
- 下单成功后发订单创建消息
- 支付成功后发积分消息
- 审核通过后同步下游
这类问题最核心的矛盾就是：
本地事务和 MQ 发送天然不是一个本地事务。
于是才有了两类常见方案：
- 事务消息
- 本地消息表（Outbox）
二、事务消息解决什么
事务消息的核心思路通常是：
- 先发半消息
- 执行本地事务
- 再确认消息提交或回滚
它更偏：
- 中间件能力兜底一致性
优点通常是：
- 一致性更直接
- 消息链路更集中
缺点通常是：
- 依赖 MQ 本身能力
- 理解和排查门槛更高
三、本地消息表解决什么
本地消息表的核心思路是：
- 业务数据和待发消息一起落库
- 后台异步扫描消息表再发 MQ
它更偏：
- 业务侧自己托底可靠投递
优点通常是：
- 更好落地
- 补偿更直观
- 不强依赖特定 MQ 特性
缺点通常是：
- 多一张表
- 多一套扫描、重试、补偿逻辑
四、怎么选更合理
我自己的建议是：
4.1 如果团队更偏业务可控、想要稳定落地
优先考虑：
- 本地消息表
4.2 如果链路特别关键，且 MQ 团队能力成熟
可以考虑：
- 事务消息
4.3 如果只是想先把问题解决掉
大多数互联网业务其实更适合：
本地消息表 + 下游幂等
因为它工程可控性更强。
五、最容易踩的坑
5.1 以为事务消息就不用幂等
错。
下游幂等依然不能少。
5.2 以为本地消息表就等于强一致
本地消息表解决的是：
- 最终一致
不是强一致。
5.3 只做方案，不做补偿和监控
不管哪种方案，没有：
- 重试
- 审计
- 告警
最后都很容易线上失控。
六、面试中怎么回答
如果面试官问你：
事务消息和本地消息表怎么选？
你可以这样回答：
第一，这两种方案本质上都在解决“本地事务和消息发送不一致”的问题，只是责任边界不同。事务消息更依赖 MQ 的能力去保证消息提交和本地事务的一致性，而本地消息表更偏业务侧自己把消息先可靠落库，再异步补发。
第二，如果团队更强调工程可控性、排障可视化和通用性，我通常更倾向于本地消息表，因为它对 MQ 的特性依赖更小，也更容易通过重试和补偿体系兜底。
第三，如果链路特别关键，且团队对事务消息的中间件能力和排障方式都比较熟，也可以考虑事务消息，但无论哪种方案，下游幂等都还是必须做。
七、总结
事务消息和本地消息表没有绝对谁更高级，关键在于：
- 你的团队更擅长什么
- 你的链路更需要什么
- 你的排障和治理能力能不能跟上
如果只记一句结论，我觉得可以记住这句：
大多数业务里，本地消息表更容易稳定落地；极关键链路里，事务消息也可以选，但最终一致性体系不能只靠中间件能力。
八、结尾
如果你觉得这篇文章对你有帮助，欢迎点赞、收藏、关注。
后面我会继续整理一些更偏实战的 Java 后端和分布式系统设计文章，尽量少写空泛概念，多写真实项目里会踩到的坑。
