企业官网建设流程全解析

微服务分散式事务治理：从 Seata 全模式到 TDSQL 实战

我在复盘一个订单中心与库存中心的数据不一致问题时，突然意识到很多人对“分布式事务”的理解还停留在“有个 Seata 就能搞定”的阶段，但实际线上情况要复杂得多。这个场景典型到几乎每个做微服务的团队都会踩一遍：下单时订单库写入成功，库存扣减却失败了，或者反过来，最终导致超卖或数据对不上。尤其是随着服务拆分粒度变细、并发量上来之后，事务的“分级治理”就不是一个可有可无的优化项，而是决定系统能否在线上安稳跑下去的关键。

这篇文章我会结合自己踩过的坑，把微服务事务从原理到落地的完整路径梳理一遍：先讲清楚为什么微服务下事务这么难，再逐个拆解 Seata 的 AT、TCC、Saga、XA 四种模式到底该怎么选、底层原理是什么，然后重点说说在 TDSQL 这种分布式数据库环境下做事务治理的实战经验和注意事项。无论你是在做订单、支付、库存这类强一致链路，还是在做积分、流水、消息这类最终一致性场景，这篇内容应该都能给你一些可以直接拿去用的参考。

1. 微服务事务为什么这么难：从 ACID 到 BASE 的艰难转身

1.1 单体时代的事务：一个数据库连接搞定一切

在单体应用时代，事务确实是简单粗暴的。一个 Spring 的@Transactional注解下去，数据库自己就能保证原子性、一致性、隔离性和持久性。扣库存和生成订单如果是在同一个数据库实例里，那就再简单不过了：BEGIN TRANSACTION，执行两条 UPDATE，COMMIT，完事。如果中途任何一个 SQL 报错，直接 ROLLBACK 把前面的操作全部回滚掉。

这个过程之所以顺畅，是因为单体应用把所有的业务数据都放在同一个数据库连接里，事务的 ACID 特性由数据库本身保证。开发人员几乎不需要额外思考，把所有数据操作塞进同一个事务方法里就安全了。但这也埋下了一个隐患：大家习惯了这种“不需要思考一致性”的编程方式，一旦系统拆成微服务，就立刻手足无措了。

1.2 微服务架构下的分布式事务困境

微服务拆分后，订单服务和库存服务各自拥有独立的数据库。问题随之而来：一个完整的业务操作，比如“下单减库存”，需要跨越两个数据库（甚至是两个物理机房、两套 MySQL 实例）来完成。单体时代的一个本地事务，被硬生生拆成了两个独立的本地事务。

这个时候，传统的 ACID 事务就无能为力了。因为分布式环境下根本没有一个“全局事务管理器”能够同时协调两个数据库的提交或回滚。你可能会想：那我在代码里先扣库存，再生成订单，如果生成订单失败就再补扣库存不行吗？理论上可以，但实际做起来问题一大堆：

第一个问题是网络不可靠。跨服务的调用可能超时，可能对方服务已经执行成功了但响应丢失，也可能服务端根本就没收到请求。你无法通过一次请求的返回结果，判断对端到底有没有真正完成操作。第二个问题是数据可见性问题。如果服务 A 扣减了库存但事务还没提交，此刻服务 B 去查询库存，看到的是旧值还是新值？整个系统的数据在某个瞬间会处于不一致的中间状态。第三个问题是局部失败的回滚补偿动作本身也可能失败，一环扣一环，处理不好就是雪崩。

1.3 强一致与最终一致：先想清楚业务到底需要什么

上面说了这么多难点，本质上是要回答一个问题：你的业务到底是否需要强一致？

我以前遇到过很多团队，一上来就说“我们要求强一致”，于是毫不犹豫上了分布式事务框架，把系统的性能、可用性全搭进去了，结果一查业务需求文档，发现根本没有那么高的要求。比如用户下单成功后，库存扣减晚几秒才反映出来，用户根本感知不到，这种场景你用最终一致性方案就足够了，没必要让整个链路去承担分布式事务的性能开销和复杂度。

根据我的经验，可以用一句话来判断：用户操作后立即返回，后续对账、扣减可以异步完成的，优先考虑最终一致；用户操作返回的瞬间，系统必须保证所有数据都已经落定、不可回退的，比如转账扣款，才需要考虑强一致方案。微服务事务治理第一步，不是急着引入技术框架，而是先想清楚业务需求的底线在哪里。想不清楚就盲目上强一致，往往是把简单问题复杂化。

2. Seata 全模式深度拆解：AT、TCC、Saga、XA 到底怎么选

2.1 Seata 的整体架构：TC、TM、RM 三个角色各司其职

先把 Seata 的基础架构讲明白。很多人 Seata 用了很久，但对它的核心组件还是一知半解，出了问题也不知道从哪排查。Seata 的三组件分别是 TC（Transaction Coordinator，事务协调器）、TM（Transaction Manager，事务管理器）和 RM（Resource Manager，资源管理器）。

TM 是发起全局事务的一端，负责向 TC 申请开启全局事务，并在业务执行完毕后发起全局提交或回滚。TC 是中心化的协调者，维护全局事务的状态，负责协调分支事务的提交与回滚。RM 则是每个参与全局事务的服务自己这边的一个组件，它负责管理分支事务，向 TC 注册分支事务，并接收 TC 的提交或回滚指令。

用个直白的比喻：TM 是项目经理，负责发起项目启动和收尾；TC 是监理方，随时跟踪每个环节的状态并发出指令；RM 就是每个施工班组的负责人，听监理的指挥。理解了这个架构，后面看每种模式的区别就会清晰很多。

2.2 AT 模式：无侵入的自动补偿方案，适合大多数业务场景

AT 模式是 Seata 最受欢迎的模式，因为它对业务代码的侵入性非常低。你只需要在业务方法上加上@GlobalTransactional注解，然后像写本地事务一样操作数据库即可，不需要像 TCC 那样写一堆 Try/Confirm/Cancel 方法。

AT 模式的原理可以从两个层面理解。第一阶段：RM 执行本地事务，同时把涉及到的数据行的前后快照（before image 和 after image）写入一张 undo_log 表中，然后立即提交本地事务，释放数据库锁。第二阶段：如果全局事务要提交，那直接删除 undo_log 里对应的记录即可；如果要回滚，RM 就用 undo_log 中的 before image 去反查当前数据，如果当前数据等于 after image，说明期间没有被其他事务改过，就把 before image 的数据补回去，完成回滚。

这里有个隐藏的关键细节，叫全局锁。在本地事务提交前，RM 会向 TC 申请对涉及数据行的全局锁，防止其他全局事务并发修改同一行数据，这样才能保证回滚时数据没有被别人动过。全局锁的管理是有性能开销的，而且如果某个分支事务持有全局锁的时间过长，会导致其他链路阻塞，形成热点问题。

AT 模式适合大多数服务间调用不算太深、链路比较短、数据一致性要求较高但允许一阶段先提交释放资源的场景。它最大的优势是开发成本低，但劣势也很明显：undo_log 表的数据量会不断累积，全局锁在热点数据上可能造成性能瓶颈，以及反射对比数据行的逻辑在字段类型复杂时可能出现兼容问题。

2.3 TCC 模式：手工补偿，性能好但开发量翻倍

如果对性能有更高的要求，或者需要使用非关系型数据库、Redis、第三方接口等不支持 ACID 事务的资源，AT 模式就用不了了，这时候可以考虑 TCC 模式。

TCC 分为 Try、Confirm、Cancel 三个阶段。Try 阶段负责资源的预留和检查，比如扣库存时不直接扣减库存数，而是先冻结指定数量的库存。Confirm 阶段在 Try 全部成功后执行，真正做业务的扣减，把冻结点掉。Cancel 阶段则在 Try 阶段任何一个环节失败时报文触发，把 Try 阶段预留的资源释放掉。

对比 AT 模式，TCC 的优点很明显：一阶段直接完成业务操作后提交，不需要持有全局锁，吞吐量和并发能力都更强。但缺点同样扎心——开发量翻倍，每个参与事务的业务接口都要额外设计冻结、确认、取消三个动作，业务表通常还需要增加冻结字段。更麻烦的是，TCC 的落地还会引入两个很隐蔽的问题：空回滚和悬挂。空回滚是指 Try 阶段没执行到，Cancel 阶段却先到了，此时必须能识别并跳过；悬挂是指 Try 执行完了但 Confirm/Cancel 一直没来，资源一直被冻结，还需要额外的恢复机制。

从我个人的实践看，一般只有在强一致性 + 高并发 + 跨多资源类型这三个条件同时满足的场景下，才值得用 TCC 去换性能。比如电商的预占库存、营销活动的扣减预算这类场景就比较合适。

2.4 Saga 模式：长事务与业务流程编排的最终选择

Saga 模式适合那种链路特别长、涉及多个微服务、每个步骤耗时都比较久的业务。它的核心思想是把一个长事务拆分为一串本地事务，每个本地事务执行完后，就向后续步骤发出下一步的指令。如果中间某一步失败，Saga 会逆序执行补偿事务，把之前已经执行成功的步骤全部回滚。

Saga 有 Choreography（编排）和 Orchestration（协调）两种实现方式。编排模式下，每个服务自己监听上一步的事件并触发下一步，没有中心节点，坏处是流程分散，链路长了很难排查。协调模式下，有一个 Saga 执行器集中管理所有步骤的调用和补偿顺序，职责更清晰，也好运维，是我们团队实际采用的方式。

Saga 模式的优点是适合长事务和异构系统，每个本地事务完成后即可提交，资源占用很少。但它的致命弱点是不保证隔离性，就是说补偿事务执行的时候，可能有其他事务读到了中间状态的数据。另外，各个步骤的数据状态推进是独立的，中间任何一刻，全局数据都处于不一致状态，所以在严格一致要求的场景下要慎用。

2.5 XA 模式：数据库原生支持，适合跨库严格一致但极看重性能的场景留坑

XA 模式是基于 X/Open DTP 模型的，它直接利用数据库本身对 XA 协议的支持来保证分布式事务。Seata 的 XA 模式需要通过@GlobalTransaction实现，最终是让多个数据库资源参与到同一个全局事务中，由 TC 来统一协调两阶段提交。

XA 的底层原理是：事务被标记为全局事务的一部分，所有分支事务的 Prepare 都成功后，才统一进行 Commit，否则全部 Rollback。这保证的是严格意义上的强一致性，回滚完全由数据库自己执行，异常处理更可靠，也不需要像 AT 那样维护 undo_log。

但 XA 的问题在于，Prepare 阶段之后，所有资源都处于锁定状态，如果全局事务整体等待时间较长，数据库连接和锁占用的时间就会非常长，在高并发场景下基本是灾难。所以 XA 模式一般只适合并发量不大、但对严格一致要求极高的场景，比如金融转账。TDSQL 本身也支持分布式事务，这为 XA 模式的落地提供了另一种可能，后文会在实战部分专门展开。

2.6 四种模式横向对比与选择逻辑

口说无凭，把四种模式的关键维度整理成一张对比表，方便大家做技术选型时直接对照：

我的选型习惯可以总结为三句话：链路短、纯数据库操作的，用 AT；有 Redis 或其他非数据库资源参与、且并发高的，用 TCC；链路长、业务天然带异步属性、中间状态可容忍的，用 Saga；至于 XA，除非业务极简单且并发极低，否则不要让它在生产环境里承担核心链路。

3. 事务分级治理策略：不要一上来就上分布式事务框架

3.1 分级治理的核心思想：能不用就不用，能少用就少用

说实话，做微服务事务治理这么久，我最深的感受是：分布式事务框架是万不得已才用的重武器，不是常规弹药。事务分级治理的第一级，是先审视业务场景能不能通过架构设计直接避免分布式事务。

举几个常见的“化整为零”手段。第一个是本地消息表。在同一个本地事务里，执行业务数据变更时，同时往一张消息表里插入一条消息记录，两者在一个库里共用一个事务，天然不会出现只成功一半的情况。然后单独有一个异步任务扫描消息表，把消息投递给 MQ，下游消费这个消息完成后续操作。这样跨服务的一致性就变成了“数据库本地事务 + 消息最终送达 + 消费端幂等”的组合。

第二个是事务消息。RocketMQ 的事务消息是这种思路的 MQ 原生实现，半消息机制可以保证本地事务和消息发送的一致性。第三个是削峰填谷，把实时的事务操作改造成异步任务加对账补偿，比如先更新订单状态为“处理中”，后台任务去协调库存扣减，最后通过定时对账发现并修复差异。

这些方案有一个共同特点：主服务不需要感知整个链路，代码复杂度低，也不存在分布式事务框架带来的性能和稳定性风险。所以在设计一个新系统时，我强烈的建议是：先穷尽业务手段，看看能不能把跨服务的强一致链路的规模降下来，能不动 Seata 就不动。

3.2 什么时候必须用 Seata：强一致场景的底线

当然，有相当一部分业务确实无法靠异步和最终一致来兜底。最典型的就是涉及资金往来的操作，比如余额扣减、转账、红包拆开后的入账。如果用户看到的余额和他实际能消费的余额不一致，哪怕只是几秒钟的延迟，都会引发严重的客诉甚至资金风险。

这个时候就必须引入 Seata 这样的分布式事务框架了。不过引入之后，依然要做事分级。我通常把系统里的事务场景按重要程度和流量特征分成三个等级：

• 等级一：核心资金链路，要求强一致，链路短，并发中等。这种直接用 Seata AT 模式或 XA 模式，配合数据库层的分布式事务能力，用最稳妥的方式保证一致。
• 等级二：非核心但要求最终一致的业务，比如积分累计、优惠券发放、消息通知。这种用事务消息或本地消息表即可，不需要上 Seata。
• 等级三：链路长、跨服务多、实时性要求不高的场景，用 Saga 或纯粹异步编排，配合状态机和定时对账。

分级定了之后，团队内部就能形成统一的技术决策依据了。最关键的一点是：不要试图用一种方案去解决所有问题，最终一致性不代表系统就不好，一致性强度要和业务成本直接挂钩。

3.3 幂等设计：任何分布式事务方案都不能替代的最后一层防护

不管选了哪种方案，幂等设计都是必须做扎实的。分布式事务的补偿机制、消息的重复投递、网络的重试，这些环节任何一个都不能保证请求只会被处理一次。我见过太多系统因为忽略了幂等，在事务回滚、消息重发时产生重复数据，最后不得不靠人工 SQL 修数据。

幂等的实现方式很常规，但对不同的资源类型要区别对待。对数据库插入操作，通常给业务订单号加唯一索引，重复插入时直接报错或忽略即可。对状态更新操作，可以用 CAS（Compare And Set），让UPDATE ... SET status = 'PROCESSED' WHERE order_id = xxx AND status = 'INIT'，只有在状态匹配时才算执行成功。对 Redis 操作，可以用 SETNX 分布式锁保证同一时刻只有一个请求能处理某个业务单号。

另外还要强调一点：幂等验证要放在业务代码的入口处，而不是嵌套在事务内部。因为一旦事务回滚，幂等校验的逻辑可能也被回滚掉了，那就起不到防重的作用了。这是个很容易被忽略的细节。

4. TDSQL 实战：分布式数据库环境下的事务与 Seata 配合落地

4.1 TDSQL 是什么：一个兼容 MySQL 的分布式关系型数据库

在微服务架构下，数据库层面也会遇到单库容量和性能的上限。TDSQL 是腾讯对外提供的一款分布式关系型数据库，比较常见的是 TDSQL-C（云原生版）和 TDSQL（分布式版）。核心卖点是兼容 MySQL 协议，对应用层来说，切换成本相对可控，同时通过分片（Sharding）把数据水平扩展到多台存储节点上。

TDSQL 的架构大致是：接入层负责 SQL 解析和转发，计算层和存储层分离，每个分片内部是类似 MySQL 的主从高可用结构。对应用开发者来说，你仍然可以用 MySQL 的语法、MySQL 的驱动去连接，但对某些操作会有隐含约束。比如关联查询如果涉及跨分片的数据，性能会大幅下降；事务如果跨了多个分片，也需要额外的分布式事务协调机制。

刚接触 TDSQL 的人最容易掉进去的坑，就是想当然地以为反正兼容 MySQL，原来怎么写的 SQL 直接搬过来就行。实际上，分片键的选择直接决定了绝大多数查询是单分片执行还是跨分片广播，这个如果设计不合理，系统根本扛不住流量。

4.2 TDSQL 与 Seata 的配合思路：数据库分布式事务与全局事务的双层叠加

在 TDSQL 环境里做微服务事务治理，有一个特殊点需要正视：TDSQL 天然具备跨分片的分布式事务能力，如果微服务拆分后每个服务的业务数据都在同一个 TDSQL 集群内，那么数据库层面的分布式事务是可以帮我们减少对 Seata 的依赖的。

举个例子，如果一个 TDSQL 集群内建了两张表，订单表和库存表，分别落在不同的分片上。当你的业务只需要操作这两个分片时，可以直接在数据库层开启一个跨分片事务，TDSQL 内部会协调两个分片的提交和回滚。这种情况下，应用层不需要额外引入 Seata，性能消耗也会小很多。

但当微服务拆得很彻底，订单数据在集群A，库存数据在集群B（或者一个在 TDSQL，一个在传统 MySQL），跨库跨集群时，数据库层的分布式事务就管不到了。此时就需要 Seata 之类的外部协调者。实践中两种方案往往是组合使用的：服务内部依赖 TDSQL 的跨分片事务保证本服务数据的强一致；服务之间的跨库调用，再用 Seata 的全局事务来兜底。

这种“双层叠加”的架构，很多人一开始不太适应，觉得复杂度上升了。但从实际落地看，它是兼顾性能和一致性的务实选择，也是分布式数据库时代微服务事务治理绕不开的新基本功。

4.3 实操：在 Spring Boot 中接入 Seata 并连接 TDSQL

接下来说一下具体的接入步骤。我先说明一个前提：以下步骤均基于常见的 Spring Boot 2.x/3.x 项目，MySQL 驱动选用 TDSQL 提供的连接地址，Seata 版本以 1.6.x/1.7.x 为例。

第一步，引入 Seata 依赖。在项目的 pom.xml 中添加 Seata 的 Spring Boot Starter，以及 Seata 对 Nacos 注册中心的适配依赖，前提是你的注册中心用 Nacos，这也是目前最常见的选择。

<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-seata</artifactId> </dependency> <dependency> <groupId>com.alibaba.nacos</groupId> <artifactId>nacos-client</artifactId> </dependency>

第二步，配置 Seata 的注册中心和配置中心。在 application.yml 中指定 Seata 的 TC 服务注册到 Nacos，并设置事务分组名：

seata: enabled: true application-id: order-service tx-service-group: order_tx_group registry: type: nacos nacos: server-addr: 127.0.0.1:8848 application: seata-server group: SEATA_GROUP config: type: nacos nacos: server-addr: 127.0.0.1:8848 group: SEATA_GROUP

第三步，在 Seata Server 的配置中，把事务分组映射到具体的 TC 集群，比如service.vgroupMapping.order_tx_group=default，这样才能让客户端找到服务端。

第四步，配置数据源代理。Seata AT 模式需要对 DataSource 进行代理，以拦截 SQL 并生成 undo_log。这一步通常是通过 Seata 的自动配置完成的，无需手动改写数据源，但需要确保相关依赖在 classpath 中。

第五步，将 TDSQL 作为业务数据库的连接配置接入 Spring Boot，这个过程和配置 MySQL 几乎一样，只是 JDBC URL 里需要带上 TDSQL 提供的连接信息：

spring: datasource: url: jdbc:mysql://tdsql-xxxx.sql.tencentcdb.com:xxxx/db_order?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: your_username password: your_password driver-class-name: com.mysql.cj.jdbc.Driver

第六步，在业务入口方法上加上全局事务注解：

@GlobalTransactional(name = "order-stock-service", rollbackFor = Exception.class) public void createOrder(OrderRequest request) { // 调用订单服务，插入订单数据 orderMapper.insert(buildOrder(request)); // 远程调用库存服务，扣减库存 stockService.deductStock(request.getSkuId(), request.getQuantity()); }

这里需要特别注意一个细节：@GlobalTransactional注解一定放在最外层入口方法上，也就是整个全局事务的起点，而不是放在每个服务内部的本地事务方法上。如果放错位置，会导致事务边界混乱，回滚逻辑错位。

关于 TDSQL 与 Seata 的兼容性，我实际测下来是需要特别注意分片键和 undo_log 表位置设置的。因为 Seata 要写入 undo_log，而 undo_log 本身也是一张业务表，如果你的业务表是分片的，undo_log 也必须存在于每个分片上，否则某个支路执行回滚时找不到对应的 undo_log 记录，就会报“undo_log not found”的错。

4.4 TDSQL 分片键设计对 Seata 和事务的影响

分片键的选择对 TDSQL 场景下的事务影响极大。分片键决定了某行数据落在哪个物理分片上，也决定了跨分片事务的规模。

如果你的业务表选择了订单号作为分片键，同一个用户的多个订单会散落在不同分片上；如果按用户 ID 分片，同一个用户的订单数据就会落在同一个分片上。对于订单中心来说，按用户 ID 分片通常更有利于单用户维度的查询和事务操作。但如果你经常需要通过订单号去查询数据，而订单号又不是分片键，那就只能走全分片扫描，代价非常大。

更麻烦的是，Seata 的 AT 模式在回滚时需要反查 before image 对应的数据行，这个操作同样受分片键的影响。如果某个分支事务操作的数据与 undo_log 记录不在同一个分片，回滚时可能会定位不到正确的物理分片。因此，在 TDSQL 上使用 Seata 时，建议把 undo_log 表设置为全局表或广播表，让它在所有分片上都存在一份完整的结构。

我在实际项目中还遇到过一种情况：某个核心业务的表设计时没规划好分片键，上线后因为查询压力太大，被迫调整分片策略，结果发现所有和 Seata 关联的 undo_log 表、事务相关的流水表都要跟着重新迁移，工作量巨大。所以分片键的设计一定要在表结构设计阶段就纳入整体考虑，而不是等业务跑起来再改。

4.5 TDSQL 原生分布式事务与 Seata 的取舍

除了配合 Seata 使用，TDSQL 本身也提供了原生的分布式事务能力。如果你的所有相关数据都在同一个 TDSQL 集群里，甚至都在同一个分片集内，那么直接使用 TDSQL 的分布式事务，效果通常比 Seata 更好。

原因很简单：Seata 在全局事务一阶段结束后，数据已经提交并释放了数据库锁，它依赖 undo_log 和全局锁做二阶段协调；而 TDSQL 的分布式事务在提交前数据一直处于事务未提交状态，所有分片要么一起成功，要么一起回滚，这种一致性更接近传统单库事务的语义。

但如果业务跨了多个独立的数据库实例，比如一个服务用 TDSQL，另一个服务用的是传统 MySQL 或 Oracle，那 TDSQL 的原生分布式事务就无能为力了，必须靠 Seata 这样的外部协调框架。

我在做技术选型时的一般判断标准是：数据集中在一个 TDSQL 实例内，并且能接受长事务锁的开销，优先用 TDSQL 原生分布式事务；数据分散在多个异构数据源，或者链路较长、不能接受长事务锁，才考虑 Seata AT/Saga 这类方案。两者不是“有我没你”的关系，完全可以共存，关键还是看每一条业务链路的具体诉求。

5. 常见问题与排查技巧实录

5.1 AT 模式回滚失败：undo_log 被误删或数据被反向修改

AT 模式上线之后，遇到过最多的问题就是二阶段回滚时报错。最常见的原因是 undo_log 记录没有成功写入，或者 after image 和当前数据不一致，导致 Seata 拒绝用旧的 before image 去覆盖数据。

排查思路可以按三步走。第一步，先查 undo_log 表里是否存在对应事务 xid 的记录，如果没有记录，要么是事务一阶段提交失败，要么是 undo_log 写入被业务代码里手动 delete 掉了。我自己就踩过这种坑：有同事写了定时任务去清理某张历史表，条件没写好，把 undo_log 表也带上了。第二步，对比一下业务表当前数据与 undo_log 中的 after_image，看是否为数值一致但二进制格式不同导致的 False 判断。第三步，看 Seata Server 的日志，找到具体是哪个分支事务回滚失败，会有明确的异常栈。

另外，AT 模式的回滚逻辑本身是：比较当前数据是否等于 after image，如果相等才允许覆盖；如果不相等，说明该行数据在全局事务执行期间被别人改了，Seata 会拒绝覆盖并抛出异常。这种保护在并发高的场景下会频繁出现。解决办法通常有两种：一是优化业务逻辑，缩短全局事务的时间窗口；二是排查是否有其他链路绕过 Seata 直接改了同一行数据。

5.2 TCC 模式中空回滚和悬挂问题的处理方法

TCC 模式里，空回滚和悬挂这两个问题，几乎每个团队都会踩到至少一次。

空回滚的场景是这样的：由于网络延迟，Try 阶段的请求还没到达参与方，参与方却先收到了 Cancel 请求。此时参与方并不知道这个全局事务的存在，如果 Cancel 逻辑里直接执行了解除冻结、释放库存等操作，就会因为找不到对应的冻结记录而报错。更严重的是，如果把“查不到记录就默认成功”的错误处理写进 Cancel，后续 Try 请求到达后执行了冻结，但这个冻结永远不会被 Confirm 或 Cancel 处理，就产生了悬挂问题。

解决办法是在参与方的业务表里增加一个事务控制表，在 Cancel 和 Try 执行前都先查一下控制表是否存在对应的事务记录。如果 Cancel 来了但控制表里没有 Try 的记录，就只写入一条状态为跳过（SKIP）的记录，不再执行真正的取消逻辑。如果 Try 来了但控制表里已经有跳过标记，就直接拒绝这个 Try，避免悬挂。这个控制在 TCC 开发中几乎是必须的。

5.3 Saga 补偿幂等与顺序问题

Saga 模式在复杂的多步链路里，补偿顺序和幂等是两个最让人头秃的问题。比如一个下单流程包含：创建订单、锁定优惠券、扣减库存、清空购物车四步。第三步扣库存失败，按逆序需要依次执行：释放优惠券、取消订单。但如果释放优惠券的服务在第二次重试中又收到一次补偿指令，而第一次补偿其实已经成功了，这就会导致优惠券被重复释放。

解决办法很简单：每个 Saga 参与方维护一张本地状态表，以全局事务 ID 和步骤 ID 作为唯一索引，补偿方法执行前先查询状态，如果该步骤已经是“已补偿”状态，就直接返回成功。多个步骤之间，补偿的顺序则可以交给 Saga 执行器维护，所以一定要选择支持有序补偿的框架或提前设计好状态机，不要自己用 MQ 去拼装。

5.4 Seata 与 TDSQL 搭配时的超时与性能问题

最后再说一个实战中很痛的问题：Seata 配合 TDSQL 后，全局事务超时和性能下降。尤其是 AT 模式下，如果某个分支事务处理时间较长，TC 会一直等待，最后触发全局超时回滚。表面看是 Seata 的问题，实际上往往是 TDSQL 分片键设计不合理，导致某个分片节点成为热点，执行 SQL 变慢，拖慢了整个分支事务。

排查这类问题上手最快的方式是看 Seata Server 的指标监控面板，观察每个全局事务从发起到最后提交的耗时分布，找出异常的分支事务。然后再到 TDSQL 的控制台查看慢 SQL 统计，定位是不是跨分片查询引起的性能问题。如果是，首选优化思路是改写 SQL 让它带上分片键的等值条件，避免跨分片广播；其次才是考虑加缓存、加索引这些常规优化手段。

TDSQL 下使用 Seata 还有一个需要特别关注的点：事务分支较多时，每个分支都会和 TC 进行多次通信，网络开销会随分支数线性增长。所以不要把一个全局事务设计得太庞大，一个事务里挂几十个分支事务不仅慢，而且一旦中间环节故障，回滚链条也很脆弱。我的习惯是，一个全局事务的分支尽量控制在五六个以内，如果超出这个范围，就要重新审视链路的合理性。

5.5 排障工具箱：日志、监控、控制台三板斧

日常维护 Seata 和 TDSQL 这套体系，我的排障三板斧是：第一，看 Seata 的 client 日志，重点看每个分支事务注册和上报的结果，关键字是xid、branchId、globalStatus。第二，看 TDSQL 的慢查询日志和分片负载监控，这一步能快速定位是不是数据库侧的问题。第三，用 Seata 可视化控制台查询全局事务状态，trace 整个事务的完整生命周期，甚至可以直接看到某个分支事务被卡在了哪个资源上。

这套三板斧用熟了之后，大部分事务问题都能在十分钟内定位到根因。最怕的是连最基础的日志都没打印好，出了故障只能靠猜，那工作量就大了。所以我一直强调，Seata 接入阶段就要把事务日志格式规范化，字段包含事务 ID、全局事务 ID、分支事务 ID、业务单号、操作类型、开始时间、结束时间和结果，后面排查数据不一致问题全靠它。

6. 事务治理落地中的一个额外建议：把对账加进最终的兜底防线

聊了这么多技术选型和框架原理，最后分享一个我自己在实战中反复验证有效的建议：不管最终选的是 Seata、TDSQL 原生分布式事务，还是事务消息，整个系统永远要补一道对账兜底机制。

对账的核心流程很简单：把核心链路上每个服务的关键数据定期比对，比如每分钟或每小时跑一个 Job，把订单库的订单状态和库存库的扣减流水做一次 diff，发现不一致就自动触发补偿任务或者告警出来人工介入。不要担心对账任务会增加开发量，实际上这套机制在关键时刻能救整个系统的命。

理由也很现实。分布式事务框架本身也不是 100% 可靠的，它只能覆盖自己能识别到的异常，像极端情况下的进程崩溃、机房断网、配置错误导致全局事务根本没生效，这些靠框架自身是无法兜住的。而对账机制从最终结果反推一致性，不管中间发生了什么，只要最终数据和预期不一致，就能被发现和修复。我在之前项目里引入对账任务后，确实避免过好几次潜在的资金事故，这些收益是实打实的。

所以我的最终建议是：微服务事务治理是一场持久战，没有一劳永逸的方案。分级是第一步，选型是第二步，对账是永远不能丢的第三步。不要迷信某一种技术能解决所有问题，务实一点，把能想到的兜底措施都做扎实，系统才能长时间稳定地跑下去。