分布式事务解决方案：跨服务的数据一致性

一、分布式事务为何是难题

单体时代，一个方法里改两张表，加个 @Transactional 就靠数据库 ACID 搞定了。微服务时代，下单要改订单库、扣库存库、加积分库，它们是三个独立数据库，本地事务管不了跨库。更要命的是：订单写成功了，扣库存时网络抖了失败了，怎么办？订单已生成但库存没扣，超卖了。这就是分布式事务问题——在多个独立资源间保证"要么都成，要么都退"，没有单机事务那么简单。它本质是在"网络不可靠、节点会挂、无共享锁"的前提下，追求某种一致性。

二、CAP 与 BASE：先端正期望

理解分布式事务前，先接受理论约束。CAP 定理：分布式系统在一致性（C）、可用性（A）、分区容错（P）三者中，网络分区（P）必然存在，所以只能在 C 和 A 间取舍。多数互联网系统选 AP（保可用、牺牲强一致），因为用户要的是"服务别挂"，短暂不一致可后续修正。BASE 理论是对 AP 的务实补充：Basically Available（基本可用）、Soft State（软状态，允许中间态）、Eventual Consistency（最终一致）。所以，微服务的分布式事务目标通常不是"强一致 ACID"，而是"最终一致"——允许短暂不一致，但保证最终对齐。端正这个期望，才不会在设计时钻牛角尖。

三、两阶段提交（2PC）：强一致但脆弱

2PC 是最经典的强一致协议：准备阶段（Prepare），协调者问所有参与者"能提交吗"，参与者锁资源并答 YES/NO；提交阶段（Commit），全 YES 则发提交指令，任一 NO 则全回滚。优点：理论强一致。缺点致命：同步阻塞（准备阶段锁资源直到提交，长事务锁表拖垮并发）；协调者单点（它挂了参与者无限等待）；数据不一致风险（提交阶段部分参与者收不到指令）；对网络超时极敏感。因此 2PC 在微服务高并发场景几乎不用，只在少数要求强一致且低并发的金融内部系统谨慎使用。它是"理论正确、工程糟糕"的典型。

三、TCC：业务层的补偿事务

TCC（Try-Confirm-Cancel）把事务拆成三个业务操作：Try（预留资源，如冻结库存而非直接扣）、Confirm（确认执行，真正扣减，幂等）、Cancel（取消，释放预留）。它是业务层面的 2PC，不依赖数据库锁，性能好很多。以转账为例：Try 阶段双方账户各冻结金额；Confirm 双方正式扣划；任一失败则 Cancel 双方解冻。TCC 的优点是避免长锁、性能好、可控；缺点是侵入业务——每个参与方都要写三个方法，且必须保证 Confirm/Cancel 幂等（网络重试会重复调用）。适合对一致性要求高、吞吐也高的核心交易（如支付、交易撮合）。

四、Saga：长事务的最终一致编排

Saga 适合"跨多个服务的长流程"（如旅行预订：订机票→订酒店→订租车，任一步失败要补偿前面）。原理：把大事务拆成一系列本地事务，每步有对应的补偿（Compensation）操作；若某步失败，按相反顺序执行前面各步的补偿，回滚整个流程。Saga 有两种协调：编排型（Choreography，各服务监听事件自发行动，去中心但难追踪）；编排器型（Orchestration，一个中央协调器驱动每步并决定补偿，易控但协调器成中心）。Saga 不保证隔离性（中间态其他事务可能读到未完成的），需业务容忍或加防脏读设计。它是微服务长流程最终一致的主流方案。

五、本地消息表 / 事务消息：可靠事件驱动

很多分布式一致性其实不需要"回滚"，而是"保证最终执行"。思路：利用本地事务+消息队列保证"业务操作"和"发通知"要么都成。本地消息表：业务库里同一事务写"业务数据"和"待发消息"，再由独立进程读消息表投递到 MQ，消费方处理并保证幂等。事务消息（如 RocketMQ）：半消息机制保证"本地事务成功才真正发消息"。这套方案把"跨服务一致"转化为"本地事务 + 可靠事件 + 消费幂等"，规避了 2PC 的脆弱，是事件驱动架构里保证最终一致的基石。关键仍是消费端幂等（见事件驱动架构篇）。

六、最大努力通知：最简最终一致

比 Saga 更轻的方案：调用方尽最大努力通知被调方执行，多次重试直到成功或放弃，最后用对账兜底。例如支付平台扣款后，反复通知商户"已支付"，商户处理；若一直失败，走线下对账补账。它不保证实时强一致，但用"重试+对账"达到最终一致，实现简单、性能好，适合对一致性要求不那么极致、但要求高可用的场景（如支付结果通知）。它的哲学是"别追求完美事务，用重试和对账兜底"，非常务实。

七、选型决策树

面对一致性需求，如何选？需要强一致且低并发、能接受锁 → 谨慎用 2PC。高一致高吞吐的核心交易 → TCC（愿写补偿代码）。长流程跨多服务、可最终一致 → Saga。跨服务只需"保证最终执行"→ 事务消息/本地消息表。可重试+对账兜底 → 最大努力通知。绝大多数互联网微服务场景，最终一致（Saga/事务消息）远比强一致（2PC）实用。核心判断维度：一致性要求多高？吞吐要求多高？能否接受中间态？业务能否写补偿逻辑？把这些问题答清，方案自然浮现。

八、幂等：分布式事务的底线

无论哪种方案，网络重试、消息重投都会让操作执行多次，因此幂等是不可绕过的前提。实现手段：业务唯一键（订单号做数据库唯一约束，重复插入直接失败）；去重表（记录已处理的事务 ID）；状态机（已支付状态重复收到支付事件不再处理）；令牌机制（每次操作带一次性 token）。没有幂等，TCC 的 Confirm 重复执行会多扣钱，Saga 的补偿重复执行会多解冻，事务消息重复消费会重复发券。幂等是分布式系统的"安全带"，必须作为基础能力内建。

九、实际架构：混合使用

真实系统不会只用一种。典型下单链路：创建订单用本地事务（单库内一致）；扣库存用 TCC（高一致高并发）；发积分、发通知用事务消息（最终一致即可）；跨服务长流程（如下单→风控→履约）用 Saga 编排。即"核心链路严（TCC/2PC 慎用）、边缘链路松（消息/最大努力）"。这种分层一致性策略，在"用户体验（别超卖）"和"系统性能（别锁死）"间取得平衡。架构师的价值，正在于为不同环节匹配恰当的一致性级别，而非一刀切。

十、Saga 编排器的实现要点

若用编排器型 Saga，要点：定义清晰的状态机（每步成功转下态，失败转补偿态）；每步持久化执行进度（防协调器重启丢失）；补偿操作必须幂等且尽力成功（补偿失败要有告警+人工介入，否则流程悬挂）；设置整体超时（防卡死）；提供可视化追踪（哪个步骤到哪了）。可借助框架（如 Axon、Camunda、Eventuate Tram）减少自研。Saga 最大的工程挑战是"补偿不完美"——某些操作无法完全回滚（如已发短信），需业务设计成"可补偿"或接受部分不可逆，用对账弥补。

十一、常见反模式

反模式一：为了"绝对一致"硬上 2PC，结果高并发下锁表、协调者挂掉全瘫。反模式二：用同步调用链跨库改数据却无事务，部分失败数据不一致还无补偿。反模式三：TCC 的 Confirm/Cancel 没做幂等，网络重试导致多扣款。反模式四：Saga 补偿逻辑漏洞，中途失败无法回滚，流程悬挂。反模式五：把分布式事务当单机事务用 @Transactional 管跨服务，完全无效。反模式六：忽视最终一致的中间态，其他业务读到脏数据出 bug。这些坑都源于"要么高估一致性能力，要么低估补偿必要性"。

十二、一致性与性能的权衡艺术

分布式事务的本质是"一致性 vs 可用性 vs 性能"的权衡。追求强一致（2PC）牺牲性能与可用；追求最终一致（消息/Saga）换来获取高性能与高可用，代价是短暂不一致。互联网系统普遍选后者，因为"短暂不一致 + 快速最终对齐"远比"为了强一致让服务卡死"对用户友好。架构师的成熟，体现在能坦然接受 BASE，并用对账、幂等、补偿把这些"最终一致"做得足够可靠，而非执着于不现实的强一致。

十三、总结

分布式事务是微服务不可回避的硬骨头。端正期望：多数场景追求最终一致（BASE）而非强一致（ACID）。2PC 理论强但工程脆弱，慎用于低并发强一致；TCC 用业务补偿换高性能，需幂等；Saga 适配长流程最终一致；事务消息/本地消息表保证"最终执行"；最大努力通知用重试+对账兜底。选型按"一致性要求、吞吐、能否写补偿"三维度决策，且务必内建幂等。真实架构是混合使用：核心链路严、边缘链路松。掌握这套权衡艺术，你就能在"数据不错、系统不卡"之间走出一条可行的路——这正是分布式系统设计的精髓。