分布式事务从原理到实践：四大方案对比与Seata AT模式深度解析

说起分布式事务，做后端的朋友应该都不陌生。我最早接触这个场景是在一个订单系统里：用户下单，订单服务要写订单表，库存服务要扣减库存。单体架构时这俩在同一个数据库里，一个本地事务就解决了。可服务一拆、数据库一分，原本一个事务能搞定的事，硬生生变成了跨服务的“分布式事务”。线上时不时就出现订单生成了但库存没扣、或者库存扣了但订单没建成的情况，数据对不上，用户来投诉，研发就得连夜排查。今天我就围绕这个场景，把这几年在分布式事务上踩过的坑、用过的方案、以及Seata背后的原理，一次性讲透。

这篇文章适合所有正在做微服务拆分、或者被跨库数据一致性折腾过的后端工程师。不管你是刚接触分布式事务的新手，还是已经在用Seata但没弄明白它到底是怎么做到的，我建议你花十几分钟，从头到尾看一遍。你会发现，看透了原理之后，选型和技术方案落地都会变得非常简单。

1. 分布式事务是怎么冒出来的：从单库到微服务的那道坎

1.1 单体时代为什么没人纠结分布式事务

先聊一个很实在的问题：在单库时代，为什么没有“分布式事务”这种说法？

因为所有业务数据都在同一个数据库里。用户下单，订单表、库存表、账户表全在一台MySQL上，你用一个 @Transactional 注解包住Service方法，数据库自带的ACID特性就能保证：要么全部操作成功，要么全部回滚。整个过程里，事务的隔离、锁、提交、回滚全部由数据库内部完成，应用层只负责声明“这里需要事务”。

这套模型最让人省心的地方在于——你不需要关心一致性是怎么保证的。数据库帮你扛住了并发、异常、崩溃恢复这些所有的脏活累活。

但微服务架构一上来，事情就变了。订单服务只管订单库，库存服务只管库存库，两个库可能部署在不同的机器上，甚至数据源都不一样。你没法用一个数据库事务去同时控制两个独立的数据源。于是“事务”这个概念被迫从数据库层面，提升到了应用和网络层面。

1.2 微服务拆分后，订单和库存“分家”了

我举个例子，你现在有一个标准的“下单”流程：

• 订单服务：写入订单表，生成一条待支付订单
• 库存服务：扣减库存数量
• 支付服务：冻结或扣除用户金额

在单体系统里，这三件事在一个库、一个事务里完成。但拆成微服务后，每个服务持有自己的数据库，服务之间的调用走的是 HTTP 或者 RPC。

问题就出现在这里。假设订单服务写库成功，然后调用库存服务扣库存，结果库存服务挂了，或者网络超时了，订单那边已经提交了。你怎么办？

• 如果直接返回失败，用户看到下单失败，但订单表里却躺着一条订单，这就是数据不一致。
• 如果把订单那边也回滚掉，你得让订单服务知道库存服务的结果，并且自己再执行一次“撤销”逻辑，可这个撤销动作本身也可能失败。
• 如果不回滚，靠后台任务对账修复，那用户在看到“下单失败”的同时，库存却被扣了，体验非常差。

服务一拆，原本数据库帮你搞定的事，现在流到了应用层，你不得不自己想办法保证跨服务的“分布式事务一致性”。

1.3 一致性模型：强一致还是最终一致，这是个业务选择题

不少人一听到“分布式事务”，第一反应就是要实现强一致：所有服务要么全部成功、要么全部失败，中间不允许出现任何状态偏差。这个想法本身没问题，但在分布式系统里，强一致是有代价的。

这里绕不开两个经典的定理：CAP定理 和 BASE理论。简单说，CAP告诉你，在网络分区的情况下，可用性和一致性只能选一个。而BASE理论其实就是一种“缓”下来的方案：允许系统在短期内存在中间状态，但保证在一段时间后，数据最终达到一致。

所以你在做技术选型之前，先别急着问“哪个框架最强”，先问自己：业务上到底能容忍多长时间的数据不一致？

举几个例子：

• 转账场景，A扣了100，B必须立刻到账，中间不允许出现“A扣了但B没收到”的状态，这种就需要强一致。
• 电商下单场景，用户下单后，库存从扣减到最终扣减完成，中间差几秒甚至几分钟，用户是无感知的。只要最终订单和库存数据对得上，就是可接受的，这种就适合最终一致。
• 秒杀场景，热点商品库存只有100件，并发可能到几千，这种高并发下如果强行做强一致，锁冲突会直接把系统压垮。

说到底，强一致和最终一致不是“哪个更好”的问题，而是“业务允不允许”的问题。搞清楚这一点，你后面选方案的时候才不会纠结。

2. 四大经典方案逐个拆解：从2PC到事务消息

2.1 两阶段提交（2PC）：教科书上的强一致方案，为什么用得少

先讲理论最完美的方案——两阶段提交（2PC）。它把分布式事务分成两个阶段：

• 准备阶段：事务协调者（Coordinator）通知所有参与者（各服务的资源管理器），让他们把本地事务准备好，并持有资源锁，但不提交。
• 提交阶段：协调者收到所有参与者的“准备成功”反馈后，再统一发出“提交”指令；只要有一个参与者准备失败，就统一发出“回滚”指令。

这个思路非常直观，数据库厂商还把它做成了标准接口，也就是XA协议。你写基于XA的全局事务时，应用层其实不用感知太多细节，数据库会帮你协调分支事务。

那问题来了：2PC在真实生产环境中，用得为什么这么少？主要是三个硬伤：

1. 同步阻塞：准备阶段所有参与者都要持锁等待协调者的最终指令。这个等待期间，数据库的这行数据是被锁住的，其他正常请求全部卡住，性能损耗非常大。
2. 单点风险：协调者如果挂了，所有参与者都不知道该提交还是回滚，只能干等。协调者重启后还得处理一堆“悬而未决”的分布式事务，恢复逻辑非常复杂。
3. 数据不一致的窗口依然存在：就算协调者发出了提交指令，如果提交指令在网络上丢了，有的参与者提交了，有的没提交，全局数据依然不一致。

所以2PC更适合那些对强一致极度敏感、并且并发量不大的场景，比如银行核心系统的某些操作。放在互联网高并发业务里，基本都会被性能问题劝退。你在做订单库存这种高并发场景时，我个人的建议是：除非业务强约束必须同步强一致，否则优先考虑下面这三种柔性方案。

2.2 TCC模式：用业务代码换性能，Try、Confirm、Cancel三步走

TCC是我在项目里实际用过比较多的方案。它的核心思想不是依赖数据库事务，而是把“预留资源”和“真正操作”拆开，通过业务代码来实现事务的提交和回滚。

TCC全称是Try-Confirm-Cancel，对应三个阶段：

• Try阶段：检查并预留资源。不是直接扣减，而是把可用资源先“冻结”起来。
• Confirm阶段：真正执行业务操作，使用Try阶段冻结的资源。
• Cancel阶段：释放Try阶段预留的资源，做反向操作。

拿订单和库存来说，具体是这样落地的：

TCC的优点是性能比2PC好得多，因为不需要长时间持有数据库锁，资源冻结的动作很轻量。但缺点也很明显：业务侵入性非常强。你需要为每个参与事务的业务方法，自己实现Try、Confirm、Cancel三段逻辑，而且每段逻辑都要保证幂等。比如Confirm阶段如果调用超时，后续重试时你必须确保不会重复扣减库存。

所以TCC适合那些业务语义清晰、且对接口性能要求较高的场景，比如电商的余额支付、积分扣减。但它对代码的侵入注定它不适合作为全站的通用方案，否则系统里的每个服务都要写一堆跟“业务无关”的补偿代码。

2.3 本地消息表：最朴素的最终一致性方案，现在还很多人用

再说一个老牌方案——本地消息表。它的设计思路非常朴素：在业务数据库里额外建一张消息表，把“写业务数据”和“写消息记录”放到同一个本地事务里，然后靠定时任务或消息中间件，把消息投递到下游服务。

流程大概是这样的：

1. 订单服务在本地事务里，同时写入订单记录和一条状态为“待发送”的消息，这两条写入在一个本地事务里，要么同时成功，要么同时失败。
2. 事务提交后，一个异步任务扫描消息表，把“待发送”的消息投递到消息中间件（RocketMQ、Kafka之类）。
3. 库存服务消费消息，执行扣库存操作，然后回执告知订单服务“消费成功”。
4. 订单服务收到回执后，把消息状态更新为“已完成”。
5. 如果消息投递失败或者消费失败，消息还在表里，定时任务会不断重试，直到成功或者人工介入。

本地消息表的优势是——它不依赖任何分布式事务中间件，纯靠数据库本地事务和消息中间件就能搞定，实现成本极低，也比较好理解。

但它的短板也很明显：消息表的数据和业务数据放在同一个库，业务量大时消息表会膨胀，而且需要自己写投递和重试逻辑。虽然开发者通常会把消息表维护得比较轻量，但从设计上看，这就是一个“手写的事务消息”。

我见过不少团队直到现在还在用这套方案，其实也不算过时，很多老系统稳定跑了好几年都没出过大数据问题。关键是正确性：消费方必须做幂等处理，因为重试机制意味着同一条消息可能会被投递多次。

2.4 事务消息：本地消息表的进阶版，可靠性更高

为了不把消息表压在业务库里，RocketMQ这类消息中间件直接实现了“事务消息”机制。它的设计其实就是在照抄本地消息表的思路，只不过把消息存储和投递挪到了消息中间件里。

事务消息的交互流程如下：

1. 生产者先发送一条“半消息”（half message）到RocketMQ，此时消息对消费者不可见，只是暂存在Broker里。
2. Broker向生产者返回“半消息发送成功”。
3. 生产者在本地执行真正的业务逻辑，比如写订单表、扣减自己的库存。
4. 如果本地事务执行成功，生产者向Broker发送“commit”指令，半消息变为正式消息，消费者就能消费了。
5. 如果本地事务失败，生产者发送“rollback”指令，Broker直接丢弃半消息。
6. 如果生产者执行完本地事务后没来得及通知Broker（比如进程崩溃），Broker会定时向生产者发起“回查”，问这半条消息到底该提交还是回滚，生产者根据本地事务状态给出答复。

事务消息比本地消息表省去了自己建表、扫表、投递的麻烦，可靠性也更高，因为消息的存储和重试都由消息中间件来保证。

实际项目中，如果你要用事务消息，我建议优先选RocketMQ，而不是把普通Kafka消息业务代码里硬包一层“伪事务”。RocketMQ对事务消息有完整的实现和回查机制，Kafka虽然也能实现类似效果，但要自己造不少轮子。

2.5 方案选型对比：到底该选哪个，看这张表就够了

讲了这么多方案，我把它们放在一起做个对比，方便你按场景对号入座：

我的建议是：如果项目里还没引入任何分布式事务方案，而且业务允许最终一致，优先考虑事务消息；如果不想引入额外中间件，本地消息表也能顶上；如果业务必须强一致且你不想写一堆TCC代码，那就用下一章要讲的Seata AT模式——这也是目前国内用得最广的分布式事务框架。

3. 解开Seata的面纱：AT模式到底做了什么

Seata是阿里开源的一套分布式事务解决方案，在国内微服务圈子里几乎是标配了。前面讲的几个方案，要么业务侵入太强，要么实现成本太高，而Seata的AT模式主打的就是“零代码侵入”，你几乎不用改业务SQL，加一个注解就能把普通方法变成分布式事务。听起来很神奇是吧？我一开始也觉得不靠谱，直到我把它的原理看明白了，才感叹这设计确实精妙。

3.1 Seata三件套：TC、TM、RM分别管什么

Seata的核心角色有三个，很多人第一次接触容易搞混，我用大白话给你梳理一下：

• TC（Transaction Coordinator）事务协调者：独立部署的Seata服务端，负责维护全局事务的状态，协调分支事务的提交和回滚。你可以把它理解成一个“总调度”。
• TM（Transaction Manager）事务管理器：它在发起全局事务的业务代码里，通过 @GlobalTransactional 注解标记一个方法作为全局事务的起点，负责向TC申请开启、提交或回滚全局事务。
• RM（Resource Manager）资源管理器：管理各分支事务的资源，它跟业务数据库打交道，负责把本地事务注册到TC，并报告分支事务的执行结果。

放到下单场景里：订单服务的下单方法加了 @GlobalTransactional 注解，它就是TM；订单库和库存库的每个数据源操作分别是一个RM；而TC是部署在另一台机器上的Seata Server，全程盯着全局事务的状态。

理解这三个角色后，AT模式的执行流程就水到渠成了。

3.2 一阶段先提交，二阶段靠撤销：undo_log立大功

AT模式最核心的亮点，是一阶段本地事务直接提交，不用长时间持锁。这比2PC“准备阶段一直锁着”要快得多。那它怎么保证一阶段直接提交后，二阶段还能回滚呢？答案就在一张表里：undo_log。

一阶段的完整过程是这样的：

1. TM发起全局事务，拿到一个全局事务ID（XID），这个XID会通过调用链一直传递到各个RM。
2. 订单服务开始执行本地SQL，比如“INSERT INTO order_table ...”。
3. RM在执行业务SQL之前，会先解析SQL，把操作的数据快照记录下来，这一步生成的是“前镜像”（before image）。
4. 执行业务SQL，再生成一份“后镜像”（after image）。
5. 把客户端信息、XID、分支ID、前后镜像这些数据组合起来，写入业务库的undo_log表，和业务SQL包在同一个本地事务里。
6. 提交本地事务，释放数据库行锁。

到这一步，业务数据已经真实生效了。如果后续所有分支都成功，二阶段就很简单：异步删除对应的undo_log记录，什么业务操作都不用做，事务就算干净利落地结束了。

如果某个分支失败，全局事务需要回滚，这时候二阶段就靠undo_log来“还原现场”：

1. TC通知所有RM回滚。
2. RM根据undo_log里的后镜像，检查当前数据库里的数据是否和“后镜像”一致。如果一致，说明这行数据没有被其他事务改过，可以放心回滚。
3. RM根据前镜像反向生成UPDATE语句，把数据还原成执行前的样子。
4. 删除undo_log记录，回滚完成。

整个过程看起来是不是很像“寄快递前先拍照验货”？一阶段货物照常发出，二阶段如果发现问题，就按照片把货物还原回来。

3.3 全局锁：防止“回滚中的数据”被别人改

看到这里你可能会问：如果一阶段提交了，别的请求也能立刻改这行数据，那二阶段回滚的时候，数据岂不是已经被别人改过了？这就要说到AT模式的另一个关键机制——全局锁。

Seata的RM在执行分支事务的本地SQL前，除了生成undo_log，还要先去TC那边申请一个“全局锁”。这个全局锁锁的是这行数据的唯一键（通常是主键），它会阻止其他Seata分支事务同时修改同一行数据。

举个例子：订单A和订单B同时扣同一个商品的库存，商品ID对应的库存行只有一个。订单A的分支事务先拿到全局锁，正常扣减并提交本地事务。订单B的分支事务去申请全局锁时，如果锁还被订单A持有着，订单B就只能等。如果订单A的整个全局事务最终要回滚，订单B一等就会超时，直接报异常，避免了它基于一个“即将被回滚”的数据继续做业务操作。

你发现没有，这个全局锁让Seata在“数据还没确定最终状态”之前，挡住了一切并发修改。它等价于用全局锁换取了分布式事务的隔离性，而undo_log则换取了一阶段直接提交的性能。这套配合，让AT模式既有了接近2PC的正确性，又只有“做一次快照”和“加一个全局锁”的额外开销。

当然，这也有代价：如果某个热点行数据被高频更新，全局锁会变成性能瓶颈，后面的请求会排队等待。不过这个代价在大多数业务场景下是可接受的，因为锁只存在于全局事务尚未结束的这段时间窗口里。

3.4 AT模式凭什么敢说自己“无侵入”

用过Seata AT模式的人都知道，接入成本低得惊人。你只需要做三件事：

1. 在全局事务的入口方法上加上 @GlobalTransactional 注解。
2. 让参与全局事务的数据源，接入Seata的代理数据源。
3. 在业务库建好undo_log表。

业务SQL完全不用改。你原来怎么写的INSERT、UPDATE，现在还怎么写。对比TCC要自己实现Try/Confirm/Cancel三套逻辑，AT模式的“无侵入”是压倒性的优势。

那AT模式有没有局限？有。因为它依赖快照和反向SQL，它只能应用于关系型数据库，而且你的业务表必须带主键，SQL也需要能被Seata解析。如果你用的是非关系型数据库，比如MongoDB、Redis，AT模式就无能为力了，只能考虑TCC这类业务级方案。

AT模式还要求每个分支事务的RM自己保存undo_log，所以参与分布式事务的每个数据库，都必须单独建这张表。漏建的话，一阶段写入undo_log时就会报错，整个全局事务直接失败。

4. 动手落地：用Seata把你的订单-库存改成分布式事务

理论讲了这么多，接下来进入实操环节。我按“部署TC → 接入微服务 → 加注解 → 验证回滚”的顺序，带你完整走一遍。

4.1 环境准备与关键配置

首先你要部署一个Seata Server，也就是TC。Seata Server可以单独下载官方发布包，解压后启动即可。生产环境建议用Docker或者Kubernetes部署，并且把它注册到你的注册中心（Nacos、Consul、Eureka都支持），方便微服务端发现它。

我以Nacos为例，TC主要需要两个配置来源：

• 注册中心配置：让TC本身注册到Nacos，微服务才能找到它。
• 配置中心配置：存放TC的配置，比如事务分组、存储模式（数据库或文件）、全局锁超时时间等。

如果你用Seata 1.4+版本，可以直接在application.yml里配置，不再像老版本那样依赖registry.conf和file.conf两个文件。核心内容大致是这样的：

yaml复制seata:
  registry:
    type: nacos
    nacos:
      server-addr: 127.0.0.1:8848
      namespace: ""
      group: SEATA_GROUP
  config:
    type: nacos
    nacos:
      server-addr: 127.0.0.1:8848
      namespace: ""
      group: SEATA_GROUP
  store:
    mode: db
    db:
      datasource: druid
      db-type: mysql
      driver-class-name: com.mysql.cj.jdbc.Driver
      url: jdbc:mysql://127.0.0.1:3306/seata_server
      user: root
      password: your_password

这里有一个容易被忽略的点：Seata Server自己的事务状态数据（全局事务、分支事务记录）建议存在数据库里，也就是 store.mode=db，而不要用默认的文件模式。因为TC如果重启了，文件模式可能丢状态；用数据库模式则能恢复，安全性更高。

4.2 三步接入：依赖、配置、加注解

服务端部署好了，接下来就是客户端接入，总共三步。

第一步，在参与分布式事务的每个微服务里，引入Seata客户端依赖。Spring Boot项目用这个（以Spring Cloud Alibaba为例）：

xml复制<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
</dependency>

第二步，配置客户端连接TC，并在服务里设置事务分组：

yaml复制spring:
  application:
    name: order-service
seata:
  enabled: true
  application-id: order-service
  tx-service-group: my_test_tx_group
  service:
    vgroup-mapping:
      my_test_tx_group: default
    grouplist:
      default: 127.0.0.1:8091

这里的 tx-service-group 是事务分组名，它必须和TC端配置的分组一致。很多新手第一次接入失败，一半以上的原因是两边分组没对上。你可以在TC控制台或者日志里看到客户端到底有没有成功注册。

第三步，在多服务调用的入口方法上，加上 @GlobalTransactional 注解：

java复制@Service
public class OrderServiceImpl implements OrderService {

    @GlobalTransactional
    @Transactional(rollbackFor = Exception.class)
    public void createOrder(OrderDTO orderDTO) {
        // 1. 写入订单表
        orderDao.insert(orderDTO);
        // 2. 调用库存服务扣库存
        stockFeignClient.deduct(orderDTO.getSkuId(), orderDTO.getCount());
        // 3. 调用账户服务扣余额
        accountFeignClient.decrease(orderDTO.getUserId(), orderDTO.getAmount());
    }
}

记住，@GlobalTransactional 要加在入口方法上，也就是跨服务调用链最上层的那个方法。下面被调用的服务方法，不需要加这个注解，它们只需要作为RM注册到全局事务里就行。

4.3 落地时的三条铁律

接入过程看着简单，但很多人在生产环境出问题，都是因为忽略了下面这三条。

第一条：全局事务方法必须通过代理调用，self-call无效。 这跟Spring事务的坑一样。如果同一个类里另一个方法调用 createOrder，而不是通过Spring注入的代理对象调用，@GlobalTransactional 注解就不会生效，全局事务直接失效，而且你还不容易发现。

第二条：事务边界要短，远程调用必须参与事务。 不要在 @GlobalTransactional 方法里做耗时的外部同步调用，比如调一个第三方支付接口等10秒，或者发短信、做大量本地计算。这些时间都会拉长全局锁的持有时间，拖垮整个链路。另外，你要让Feign/RestTemplate调用把XID传递到下游服务，Seata的过滤器会默认帮你透传XID，前提是你两个服务都正确接入了Seata，而且没乱改请求头。

第三条：先想清楚回滚场景，再写业务代码。 AT模式下，回滚依赖undo_log自动反转SQL，但这不代表你的代码可以为所欲为。比如你在业务SQL里用了 NOW()、UUID() 这类非幂等函数，或者在服务之间做了无法回滚的外部副作用操作（比如发了邮件、调了短信），那就算数据库回滚成功了，业务上依然是不一致的。所以涉及外部副作用的操作，最好挪到全局事务提交成功后再做。

5. 生产环境踩坑实录：真实故障排查笔记

Seata虽然在原理和设计上很优秀，但真搬到生产环境，坑也不少。下面几条是我和团队在线上实打实踩过的，整理出来分享给大家，能帮你少走几个月弯路。

5.1 全局锁等待超时：最经典的高频报错

报错关键字：GlobalLockWaitTimeoutException 或者 Lock wait timeout exceeded。

这个错误大概率出现在高并发同时更新同一行数据的场景，比如秒杀扣库存。为什么？因为AT模式要求分支事务在执行SQL前获取全局锁，这一步是串行的。同一个商品SKU的库存只有一行，所有下单请求都在抢这行数据的全局锁，锁竞争一激烈，后面的请求就不断等待，超过默认的锁等待时间就抛异常了。

我当时遇到的情况是上线了一个促销活动，预热时一切正常，活动开始后订单成功率雪崩，日志里全是全局锁等待超时。排查下来就是热点库存行被全局锁卡死了。

解决办法有几个思路：

1. 调整全局锁重试时间，在Seata配置里调大锁重试次数或间隔。但这只是缓兵之计，锁等待时间变长，整个接口的RT也变长了，治标不治本。
2. 把热点行的更新拆分，比如库存字段拆成多个子库存桶，分散到多行，降低行锁竞争。
3. 更换方案，这种强热点场景，优先考虑TCC或者异步化扣减（比如Redis预扣 + 消息异步落库），不要硬上AT模式。

5.2 回滚失败：脏写、undo_log被删、SQL解析不了

回滚失败是最让人头秃的问题，因为数据已经错了，你还得手工修。我总结了几种典型的回滚失败原因：

• 脏写检测不过：二阶段回滚时，RM要用后镜像对比当前数据。如果全局事务提交之前，这行数据就被其他非Seata管理的请求偷偷改了（比如DBA手工UPDATE、报表系统直连库写数据），对比就不一致，Seata会拒绝回滚并抛出异常。
• undo_log记录被误删：有些团队把undo_log当成了日志表，加了定时清理任务，结果把还没回滚的undo_log给删了。记住，undo_log是事务数据，不能随便清理，它只在全局事务提交后才允许删除。
• SQL解析不了：Seata对复杂SQL的支持有限，特别是多表JOIN的UPDATE、批量UPDATE、部分DDL操作，可能会解析失败，导致生成不了前后镜像。这类SQL只能自己改造，或者在接入层绕过。

5.3 脏读问题：AT模式默认隔离级别要心里有数

AT模式的默认全局隔离级别是“读未提交”。什么意思？就是一个全局事务还没提交的时候，它改过的数据对其他事务是可见的。这在大多数业务里没问题，因为全局事务的期间非常短，而且等它提交了数据本来就是可见的。但如果你的业务要求“读已提交”，也就是不能读到未提交的中间数据，那就要针对这类读操作，手动加上 SELECT ... FOR UPDATE，用全局锁保证读的时候不会读到中间状态。

这个细节容易被人忽略。有一次生产环境做活动，运营后台看到一个商品的销量突然变成了负数，非常久才恢复。排查后发现就是报表服务直接查了库存表，读到了另一个全局事务还没提交的中间状态。解决方式就是让报表查询加FOR UPDATE，或者改查从库（延迟几秒，天然避开了全局事务窗口期）。

5.4 常见问题速查表

最后整理一份排障速查表，方便你遇到问题直接对号入座：

undo_log表的标准结构，这里也一并给出来，你在每个参与事务的业务数据库里建一下：

sql复制CREATE TABLE `undo_log` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `branch_id` bigint(20) NOT NULL,
  `xid` varchar(128) NOT NULL,
  `context` varchar(128) NOT NULL,
  `rollback_info` longblob NOT NULL,
  `log_status` int(11) NOT NULL,
  `log_created` datetime NOT NULL,
  `log_modified` datetime NOT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_branch_id` (`branch_id`),
  KEY `idx_xid` (`xid`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4;

我记得官方新版本的脚本里多了id主键和索引字段，直接用上面这版是没问题的。建表时要注意，每个业务库都要建，而不是只在订单库或库存库建一个。

折腾了这几年分布式事务，我最深的体会是：不要在系统设计阶段就给分布式事务“判死刑”，也不必一上来就上最重的框架。先把业务场景读清楚——你的核心路径到底能不能容忍秒级不一致？如果不能，AT模式够不够用？热点数据集中度高不高，要不要考虑TCC？你的项目里已经有哪些基础设施，重复利用是不是更省钱？

还有一个建议值得分享：不管选了哪套方案，都要把幂等和监控当成一等公民。分布式世界里，重试和延迟是常态，没有幂等保护，再好的事务框架也会被网络抖动击穿。日志里把XID、分支ID、TC的决策时间全部打上，出问题时才能快速定位是哪个环节拖了后腿。

从订单库存这种典型场景切入，把分布式事务的原理和实践都过一遍之后，你会发现它其实没有想象中那么玄乎。理解每套方案的取舍，结合业务节奏做选择，剩下的就是靠工程实践持续打磨了。希望这篇分享能帮你在自己的项目里少踩几个坑，做技术选型的时候心里更有底。