微服务分布式事务方案选型：2PC、TCC、SAGA与消息事务实战解析

做微服务的时间久了，你迟早会遇到一个叫“分布式事务”的坎。我印象最深的一次，是凌晨两点被电话叫醒，说线上订单和库存对不上。查了半天，订单创建成功了，库存扣减却在远程调用超时后被回滚了，用户的账单上留下了一笔“幽灵订单”。从那以后我就明白了，微服务架构里，分布式事务不是一个“要不要学”的技术问题，而是一个“迟早得面对”的业务问题。

这篇文章我会结合实际的项目实践，把分布式事务的几个主流方案——2PC、TCC、SAGA、本地消息表、MQ事务消息——的原理、代价和选型思路都拆开讲清楚。既适合正在做微服务改造的开发者，也适合准备面试、想把这块讲明白的人。核心不是说哪个方案最好，而是帮你建立一套判断逻辑：在什么场景下，选什么方案，付出的代价是什么。

1. 从订单扣库存说起：分布式事务到底在解决什么

1.1 一个本地事务为什么管不住跨服务操作

先看一个最经典的场景：下单。在单体应用时代，订单表和库存表在同一张数据库里，你只需要开一个本地事务，扣库存、建订单、加流水，要么全成功要么全失败，ACID四个特性由数据库帮你兜底。

微服务拆分以后，订单服务有订单库，库存服务有库存库。一次下单操作，本质上是“订单服务写库 + 远程调用库存服务扣减”。传统本地事务的边界只在自己那个数据库内部，根本管不住这次跨服务、跨库的调用链。如果订单库提交成功、库存服务因为网络超时没扣成，两边数据就永远对不上了。

这里有个关键认知：分布式事务的本质，不是“把分布式操作变成本地事务”，而是“在无法保证原子性的前提下，通过一系列机制让数据最终达成一致”。它处理的核心矛盾是：网络不可靠、服务可能宕机、数据无法一把锁住。搞清楚了这一点，你再看各种方案，思路会清晰很多。

1.2 分布式事务的本质是一个“一致性取舍题”

很多人一上来就纠结“用哪个框架”，其实第一步应该想清楚：你的业务能接受多大的不一致窗口。

• 金融转账、支付扣款，这种场景用户对金额高度敏感，连“短暂不一致”都不太能忍。
• 订单创建、积分赠送、发短信通知，这种场景稍微延迟几秒甚至几分钟，用户基本感知不到。
• 搜索索引更新、缓存刷新、报表统计，这种场景根本不需要强一致，异步做掉就行。

分布式事务的各种方案，本质上就是在一致性强度、可用性、性能、业务侵入性这四个维度之间做取舍。没有免费的午餐，你选了强一致，就要接受性能损失和实现复杂度；你选了最终一致，就得在中途状态可被观测、需补偿的方向上做文章。

我给很多团队做过技术评审，最常见的分歧就是：产品经理坚持“数据必须完全一致”，而研发觉得“最终一致就行了”。这种分歧不解决，方案选型就是空中楼阁。所以第一步一定先把业务对一致性的容忍度聊透。

2. 主流分布式事务方案的原理拆解与真实代价

2.1 2PC/XA/AT：强一致但代价不低

两阶段提交（2PC）是分布式事务最经典的实现思路，XA协议就是它的数据库标准实现。整个过程分两步：

• 准备阶段：协调者问所有参与者“能不能提交”，各参与者执行事务但先不提交，而是写日志、锁资源，然后回复“OK”。
• 提交阶段：协调者收到所有“OK”后，广播提交指令，各参与者正式提交；只要有一个参与者说“不行”，协调者就广播回滚。

听起来逻辑很严谨，但2PC有个著名的软肋：阻塞。准备阶段参与者持有的数据库锁不会释放，一旦协调者宕机，参与者就只能一直等下去。这也是为什么传统XA方案在互联网高并发场景下很难铺开的原因——它不是不能保证一致性，而是为了保证一致性把系统吞吐锁死了。

后来Seata的AT模式在XA思路上做了优化，引入了全局锁和undo_log。它通过代理数据源自动记录操作前后镜像，提交时生成undo_log，回滚时根据undo_log反向补偿。对业务代码侵入非常小，一个@GlobalTransactional注解就能用起来。但它本质上还是2PC思想，换来的是性能损耗——本地事务提交前需要检查全局锁，高竞争场景下锁等待会很酸爽。

2.2 TCC：业务侵入性强但性能好

TCC是最“硬核”的一个方案，它把每个操作拆成三个业务方法：

• Try：资源预留。比如下单时先把库存锁定，不实际扣减。
• Confirm：确认执行业务。Try全部成功后，真正扣减库存。
• Cancel：取消执行。Try有任何一步失败，释放预留的资源。

TCC的优势是性能好、没有长事务锁，因为Try阶段只做预占操作，业务动作真正执行是在Confirm阶段，单条链路非常短。但它的代价也相当直白：每个业务都得实现三个方法，而且要考虑并发冲突、幂等、悬挂等一堆边界情况，代码量明显增加。

很多人做TCC踩坑，都是踩在同一个地方——Try阶段的资源预留设计得不合理。比如扣库存的Try只是简单做了一次update stock set num = num - 1，这其实是强扣，不是预留。真正的预留应该是update stock set frozen = frozen + 1这样把资源冻结起来。我在项目里见过多个团队把TCC做成“伪TCC”，最后根本没起到预留效果，一发生并发就超卖。

2.3 SAGA：长事务的补偿艺术

SAGA的核心思想是：把一个大事务拆成多个有序的本地子事务，每个子事务都配一个对应的补偿操作。正向操作执行到哪一步失败了，就反向调用已经成功步骤的补偿操作。

比如一个完整的下单流程：创建订单 → 扣减库存 → 调用支付 → 发送积分。如果支付失败，就依次冲正积分、取消支付、加回库存、作废订单。SAGA非常适合这种业务流程长、跨越多个服务的场景。

SAGA有两种实现模式：

• 编排模式（Orchestration）：由一个中央协调器（比如状态机引擎）控制每一步的调用和补偿，流程集中管理，直观易懂。
• 协同模式（Choreography）：每个服务完成后通过消息事件触发下一个服务，没有中央协调器，节点更松耦合。

我见过很多团队选用SAGA状态机引擎（如Seata的SAGA模式）来编排长流程，把每一步的输入、输出、补偿策略配成一张表，代码里几乎不用写复杂的回调逻辑。但状态机配出来只是第一步，真正难的是要保证每一步操作本身是幂等的，否则补偿操作重复执行一次，库存就多扣一次。这一点经常被忽略，我后面会专门展开。

2.4 本地消息表与MQ事务消息：最终一致性的主流实践

如果把业务拆成“主流程 + 可异步化的从流程”，分布式事务问题会简单很多。比如“下单成功之后发短信通知用户”这种操作，完全没必要和订单创建放在同一个分布式事务里。把消息可靠地投递出去，让消费端异步执行，就能在性能和一致性之间取得很好的平衡。

这个思路有两个经典实现。

本地消息表的做法是：在业务库中建一张消息表，把“写业务数据”和“写消息记录”放在同一个本地事务里，然后通过一个定时任务把消息表中的未发送记录扫描出来，投递到MQ，投递成功后再把消息状态更新为已发送。它的核心是“靠数据库事务保证消息必达”，缺点嘛——业务表多一张消息表，发送逻辑要在业务代码里显式触发，定时投递也有一定的延时。

MQ事务消息则把消息的可靠性交给消息中间件，以RocketMQ的事务消息最为典型。生产者先发送一条“半消息”，此时消息对消费者不可见；然后执行本地事务，根据结果向MQ提交或回滚。如果执行过程中进程挂了，MQ会主动回查生产者的本地事务状态，再决定最终投递还是删除半消息。这样就把“本地执行”和“消息发送”这两个动作的原子性交给MQ来协调，业务侧实现成本会比本地消息表低不少。

我自己在实际项目里，能用MQ事务消息解决的，绝不轻易上TCC。因为大多数分布式业务场景，并不需要那种“实时强一致”的物理保证，最终一致就够了。

3. 选型不只看技术，更要看业务能接受哪种“不一致”

3.1 一致性要求分级：强一致、弱一致、最终一致

分布式事务选型，本质上是回答一个问题：业务能接受多久、多大范围的中间不一致？

我习惯把业务场景按一致性要求分成三个等级。

• 强一致：任何时刻，任何节点看到的数据都必须完全一致。典型场景是跨行转账、余额扣减，用户查询余额的一瞬间，结果必须是准确的。这类场景最好使用2PC、TCC这类强一致性方案。
• 弱一致：允许短暂不一致，但最终会收敛。典型场景是订单创建后同步购物车、发送短信通知、生成物流信息。多等几秒几乎不可感知，用可靠消息方案就足够。
• 最终一致：容忍一个较长的不一致窗口，通过异步任务逐步补齐。典型场景是ES索引同步、数据统计分析。直接用MQ广播加上定时对账就能解决。

给大家一个快速判断方法：如果数据不一致的“后果”能被用户感知、引发资损或者法律纠纷，那优先用强一致；如果只是内部系统的短暂延迟，那就别让分布式事务的复杂度绑架整个业务，老老实实走最终一致。

3.2 业务场景与方案选型对照

每次做技术方案评审时，我习惯先把需求放到一张对照表里，然后再聊方案，效率非常高。

需要特别提醒的是，同一个系统里的不同业务，完全可以有不同的选择。比如核心支付走TCC，订单创建走MQ事务消息，搜索结果同步走普通MQ。不要幻想“一套分布式事务方案打天下”，这跟“一套设计模式解所有需求”一样不切实际。

我见过一个团队，为了统一技术栈，把所有场景全部强制用Seata AT模式处理。结果一个毫秒级的扣库存接口，因为全局锁等待动不动就超时，性能压测完全过不了。后来我把“发送短信”、“更新活动状态”这类不痛不痒的从流程全部改成MQ异步，核心交易链路才喘过气来。

4. MQ事务消息的落地细节：以RocketMQ为例

4.1 事务消息的执行流程

以RocketMQ为例，事务消息的完整流程是这样的：

1. 生产者向MQ发送一条半消息，此时消息在Broker端，但对消费者不可见。
2. 生产者执行本地事务（比如创建订单、扣库存），执行成功则返回COMMIT，失败则返回ROLLBACK。
3. Broker收到COMMIT后把半消息转为正式消息，消费者就能拉取到了；收到ROLLBACK则删除半消息。
4. 如果生产者执行本地事务时挂了，或Broker迟迟没收到明确结果，Broker会定时调用生产者提供的回查接口，询问“这条半消息对应的本地事务到底成没成”。
5. 生产者根据本地事务状态返回COMMIT或ROLLBACK。

在代码层面，你需要实现TransactionListener接口：

java复制public class OrderTransactionListener implements TransactionListener {

    @Override
    public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
        // 这里执行本地事务，比如写订单表
        try {
            orderService.createOrder((OrderDO) arg);
            return LocalTransactionState.COMMIT_MESSAGE;
        } catch (Exception e) {
            return LocalTransactionState.ROLLBACK_MESSAGE;
        }
    }

    @Override
    public LocalTransactionState checkLocalTransaction(MessageExt msg) {
        // 回查：根据消息内容中的订单号，查本地订单是否存在
        String orderId = msg.getKeys();
        boolean exists = orderService.checkOrderExists(orderId);
        return exists ? LocalTransactionState.COMMIT_MESSAGE
                      : LocalTransactionState.ROLLBACK_MESSAGE;
    }
}

4.2 回查机制的正确实现

回查是事务消息的核心保险，但很多人在这一环节偷懒了——直接在回查方法里返回UNKNOW，或者只做一个简单的分布式锁检查。回查的覆盖率直接决定了最终一致性的兜底能力，不能马虎。

回查设计有两个关键原则。

第一，回查必须能查到“真实状态”。事务消息的回查不是查“消息有没有发出去”，而是查“本地事务到底有没有成功”。所以你要用业务主键（比如订单号）作为消息的keys，回查时通过幂等查询判断本地事务是否已提交。我曾经见过一个团队在回查里查的是消息表的记录状态，结果本地事务已经提交、但消息表的记录因为脏数据被更新了，导致Broker正确回滚了一条本应投递的消息，用户下单成功却永远收不到确认通知。

第二，回查接口必须偶幂等、可重入。Broker的回查会持续一段时间，并且可能并发触发多次。如果你的回查逻辑本身因为并发异常而返回了错误状态，最终一致性就破了。

4.3 消费端幂等设计

很多人会忽略一件事：MQ提供的是至少一次投递，不是恰好一次投递。消费端可能因为网络、重启等原因收到重复消息。

比如库存服务消费“扣减库存”消息，如果同一个消息被消费两次，库存就被扣了两次，用户下了一单结果扣了两件货。这种问题靠MQ本身无法解决，必须在消费端做幂等。

常用做法是建一张消费幂等表，以消息的全局唯一ID作为主键。消费逻辑在同一个本地事务里先去插幂等表，插入成功说明这条消息是第一次处理，可以继续执行业务逻辑；插入失败就说明已经处理过，直接返回成功。

sql复制CREATE TABLE `mq_consume_log` (
  `message_id` varchar(64) NOT NULL COMMENT '全局消息ID',
  `biz_key` varchar(64) NOT NULL COMMENT '业务唯一键',
  `consume_status` tinyint NOT NULL DEFAULT '0',
  `consume_time` datetime DEFAULT NULL,
  PRIMARY KEY (`message_id`),
  UNIQUE KEY `uk_biz_key` (`biz_key`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='消息消费幂等表';

这里有个小技巧：幂等表的关键其实不是message_id，而是biz_key。因为同一个业务操作可能因为重试产生不同的message_id，但业务唯一键是一致的。比如扣库存消息里带有订单号+商品ID+扣减数量，那么biz_key就应该是“订单号+商品ID”。这样即使上游生产端重试产生了多条不同ID的消息，消费端也能精确识别是同一笔操作。

5. 真实的坑与排查思路

5.1 消息丢失与重复消费

消息丢失是最终一致性方案里最头疼的问题。常见原因有三种：

• 生产端没等MQ返回发送成功就继续走流程。解决方式：发送结果要同步等待，失败要有重试机制。
• 半消息提交前进程崩溃，回查也没及时触发。解决方式：回查机制一定要完善，别依赖“刚好没崩”。
• 消费端处理出现异常就直接丢弃。解决方式：消费失败必须重试，重试也失败要进死信队列或告警，不能默默吞掉。

针对消费端的重复消费，核心思路就是我前面说的幂等表。还有一个补充手段是每天跑一次对账任务，对比订单表的订单状态和库存扣减流水，发现不一致的自动触发补偿。

我在实践中总结了一个排查思路，供大家参考。当订单和库存对不上时，按下面顺序顺藤摸瓜：

1. 先查订单表状态和库存流水，确定谁多谁少。
2. 查MQ的消费日志，看消息是否被消费过、消费结果是成功还是失败。
3. 查消费幂等表，确认有没有重复消费或漏消费。
4. 查死信队列，看看有没有长时间重试失败的消息。
5. 如果都查不出来，最后用对账任务把差异明细筛出来，人工或自动补偿。

5.2 全局锁竞争导致性能下降

使用Seata AT模式时，最典型的性能瓶颈就是全局锁竞争。AT模式在本地事务提交前，需要去Seata Server申请全局锁；同一行数据在同一时间只能被一个全局事务持有锁。当高并发大量更新同一行库存时，全局锁等待会拖垮整个接口的响应时间。

有次压测，扣库存接口在300并发时P99就飙到了800ms，TPS上不去。排查后发现是Seata全局锁竞争导致的大量锁等待。解决方案是把“强一致+高并发+行数据热点集中”这类场景的分布式事务拿掉，改用MQ异步削峰。库存扣减本来就是可以异步化的，没必要为了强一致牺牲性能。

另外还要注意AT模式下的脏读问题。因为AT模式在本地事务提交后、全局事务提交前，数据对外是可见的。如果其他事务读到这个中间状态，就会产生脏读。Seata通过引入select for update + undo_log快照能在一定程度上隔离读未提交的脏数据，但要完全避免脏读，需要业务侧自行控制。所以涉及资金、库存这类核心敏感数据，别指望AT模式“自动”帮你解决所有问题。

5.3 补偿和冲正逻辑的幂等

最后专门讲一下补偿逻辑的幂等，因为这是最容易出生产事故的地方。

无论是TCC的Cancel、SAGA的补偿操作，还是本地消息表里的定时重发，都必须保证同一个补偿操作重复执行多次，结果和只执行一次完全一样。

一个典型的反例是，库存扣减的Cancel方法直接update stock set num = num + 原扣减数。如果Cancel因为网络重试被调用了两次，库存就多加了两次。正确的做法是取消时要有操作流水号作为唯一索引，Cancel执行前先查流水号，已经存在就直接返回成功。

在设计冲正逻辑时，我一般会遵循三个要点：

• 每条业务操作都有一个不重复的流水号。冲正时用流水号去查有没有执行过，有则直接幂等返回。
• 冲正操作本身要记录状态，至少包括初始、处理中、完成、失败，方便对账和人工介入。
• 冲正失败不能无脑重试，要有最大次数限制，超过后走告警和人工处理。否则一个BUG引发的僵尸重试就可能把积压的消息变成雪崩。

还有一个隐藏比较深的坑：补偿操作与主流程操作共用同一套代码时，容易重复扣减。比如主流程扣库存是“订单服务调库存服务扣减接口”，补偿操作也许直接调库存服务“冲正接口”。如果冲正接口内部的判断逻辑不够严谨，很可能把“未扣减成功”也记录成一次冲正成功。所以我的经验是，补偿操作的代码必须单独定义，和主流程代码严格分离，并且每一步都要有明确的状态流转。

写在最后的个人体会

分布式事务做了这么多年，我的体会是：没有银弹，只有取舍。2PC强一致但性能差，TCC性能好但侵入性强，SAGA适合长流程但补偿逻辑复杂，消息方案最终一致但有延时窗口。真正可靠的系统，往往是几个方案组合使用的结果——核心链路用TCC或AT，异步环节走事务消息，外围同步用普通MQ加对账兜底。

最后分享一个小技巧：不管用了哪个方案，都别忘了加一个定期对账系统。对账是分布式事务的最后一道防线，它能发现那些“理论上不会发生”但实际就是发生了的脏数据。很多团队在做分布式事务时把精力都花在方案选型上，却忽略了对账兜底，结果线上出了数据不一致，排查起来无比痛苦。有了对账任务，再配合监控告警，你才能在睡梦中安心——至少真出了问题，系统能自己抓住异常。