微服务数据一致性:从2PC到Saga,如何选择适合你的分布式事务方案
上周和团队复盘一个线上问题,起因很简单:用户下单后扣款成功,但订单状态却卡在了“处理中”。几个微服务之间的数据对不上,排查了大半天。
这场景是不是很熟悉?
在微服务架构里,数据一致性就像房间里的大象——人人都知道它存在,却常常选择暂时忽略,直到它真的撞翻了东西。
今天我们不谈空洞的理论,就聊聊这些年踩过的坑、用过的方案,以及最关键的那个问题:面对不同的业务场景,到底该选哪个?
别急着选方案,先问自己三个问题
很多人一上来就研究TCC、Saga哪个更牛,其实方向错了。
我习惯在技术选型前,先和业务、产品同学坐下来,搞清楚三件事:
- 这笔“交易”失败的概率有多高? 是像电商下单这种高频操作,还是像企业合同审批这种低频但重要的流程?
- 用户能等多长时间? 支付需要实时反馈,但物流状态更新晚几分钟可能没关系。
- 最坏情况下的补偿成本是多少? 是能自动退款了事,还是需要人工介入、甚至引发客诉?
答案不同,选择的技术路径会天差地别。
主流方案对比:没有银弹,只有权衡
1. 两阶段提交(2PC):经典的“重武器”
它是什么:你可以把它想象成一次严肃的会议表决。协调者(Coordinator)问所有参与者(数据库/服务):“准备好了吗?”(第一阶段)。大家都说“Yes”,才正式提交(第二阶段)。
真实体验:
- 优点:强一致性保证,符合ACID直觉,适合银行转账这类对一致性要求极高的核心场景。
- 痛点:同步阻塞是致命伤。任何一个参与者卡住,整个事务都会挂起,资源被长时间锁定。性能瓶颈明显,在高并发下很难用。
我的建议:除非是金融核心链路且交易量不大,否则在微服务中慎用2PC。它太重了。
2. TCC(Try-Confirm-Cancel):业务侵入的“精细操作”
它是什么:把一个大事务拆成三个可补偿的业务阶段。
- Try:预留资源(如冻结库存、预扣款)。
- Confirm:真正提交(扣款、减库存)。
- Cancel:回滚(解冻、退款)。
真实体验:
- 我们曾在一个促销系统中用TCC处理秒杀订单。Try阶段只做库存检查与预留,极大缓解了数据库压力。
- 最大的成本不在技术,而在业务。你需要为每个参与服务设计三个接口,补偿逻辑要覆盖所有边界情况,代码量几乎翻倍。
- 适合业务清晰、补偿逻辑明确、对一致性要求高的场景,比如交易、库存。
3. Saga:最终一致的“长跑选手”
它是什么:把一个分布式事务拆成一连串本地事务,每个事务都有对应的补偿操作。执行顺序可以是协同式(事件驱动)或编排式(中央协调)。
真实体验:
- 我们用一个编排式Saga重构了订单履约流程(下单→支付→发货→通知)。流程清晰,每个服务只关心自己的事。
- 它接受“中间状态”。用户可能看到“已支付,待发货”,这是最终一致性的体现。
- 难点在于“等幂性”和“可观测性”。网络超时导致补偿指令重发怎么办?一个环节卡住了,如何快速定位和手动干预?
- 适合流程长、异步、允许短暂不一致的场景,如旅行订票(订机票、酒店、租车)。
4. 本地消息表:朴素的“可靠信使”
它是什么:业务数据和消息日志保存在同一个数据库事务里,通过后台任务异步投递消息,利用重试机制保证最终到达。
真实体验:
- 这是很多团队最早自研的方案,技术门槛低。我们用它处理用户注册后的初始化工序(送优惠券、发欢迎邮件)。
- 简单,但也意味着功能少。没有全局事务状态管理,补偿需要自己写。消息积压时监控和清理比较麻烦。
- 适合数据敏感性不高、允许延迟、想快速落地的辅助业务流程。
5. 事务消息:借力中间件的“捷径”
它是什么:RocketMQ等消息队列提供的功能。生产者先发一个“半消息”,等本地事务成功后再确认发送,否则回滚。
真实体验:
- 用起来很爽,尤其是和RocketMQ集成时,省去了自己维护消息表的麻烦。
- 但严重依赖特定中间件,架构选型被绑定。并且,它只解决了消息可靠投递,事务的整体回滚逻辑仍需业务方设计。
- 适合已经深度使用相关MQ且事务模式为“发通知”的场景。
一张图帮你做选择
坦白讲,没有最好的,只有最合适的。我总结了一个简单的决策思路:
[你的业务场景]
|
┌─────────────┴─────────────┐
│ │
要求强一致性 接受最终一致性
(ACID-like) (BASE理论)
│ │
交易量不大? 流程长且异步?
┌─────┴─────┐ ┌──────┴──────┐
│ │ │ │
是 否 是 否
│ │ │ │
考虑【2PC】 考虑【TCC】 考虑【Saga】 考虑【本地消息表】或【事务消息】
(金融核心) (交易、库存) (订单履约、订票) (日志、通知类)几个容易被忽略的关键点
- 监控比实现更重要:再完美的方案也会出错。必须要有清晰的事务状态看板、链路追踪和告警,能快速回答“这个异常订单卡在哪了?”
- 补偿不是万能的:有些操作无法补偿,比如发送短信。这类操作要尽量放在事务末尾。
- 与团队能力匹配:如果团队对事件驱动不熟,强上Saga可能适得其反。从简单的本地消息表开始,理解模式,再迭代升级,往往是更稳妥的路径。
写在最后
微服务下的数据一致性,本质上是一个业务问题的技术体现。
别再寻找那个“一劳永逸”的完美方案了。真正的答案,藏在你的业务特性、团队经验和运维能力之中。从最简单的需求开始,选择一个可理解、可维护、可监控的方案,远比追求技术的“先进性”来得实在。
毕竟,能让系统稳定运行,让数据大致对齐,让团队睡得着觉的方案,就是好方案。
你目前在为哪种业务场景寻找一致性方案?遇到了什么具体困难?欢迎分享出来,我们一起聊聊。
