企业官网建设流程全解析

做后端这些年，只要系统从单体拆成微服务，分布式事务的问题迟早会撞到你脸上。最开始你可能觉得“不就是跨库写数据嘛，手动补偿一下就行”，等真正上线跑起来，数据对不上、订单状态漂移、库存扣了但支付没成功，这时候才会意识到：分布式事务不是加个补偿接口就能糊弄过去的事。业界主流的开源中间件里，Seata 的 AT 模式和 TCC 模式是两个绕不开的落地方案。

这篇文章我想把这两种模式掰开揉碎地讲一遍：它们各自是怎么工作的，为什么能做到最终一致，在真实项目里分别适合什么场景，以及我一路上踩过的坑。无论你是在做电商交易、支付清结算，还是任何涉及跨服务调用的业务系统，这篇文章都能帮你建立一个清晰的选型判断和排障思路。

1. 微服务化之后，分布式事务为何绕不开

1.1 单机事务失效的根因

单体架构里，一个事务基本等于一次数据库操作：BEGIN、执行SQL、COMMIT 或者 ROLLBACK。数据库自己通过 Redo Log、Undo Log、行锁、MVCC 等等机制把 ACID 四个特性保证得明明白白。你不需要关心事务怎么回滚，出错了数据库帮你回滚。

微服务化之后，问题一下就变了。原来在一个库里的一张订单表和一个库存表，现在变成了订单服务负责订单库、库存服务负责库存库、账户服务负责账户库。一次用户下单可能要同时往三个库写数据，而这三个库彼此之间没有分布式协调能力。数据库层面能保证的原子性只限于“单个库内的事务”，跨库跨服务之后，“要么全成功、要么全失败”就变成了一件需要应用层自己解决的问题。

我见过很多团队的第一反应是：我们尽量通过接口设计避免跨服务事务，比如把订单和库存放进同一个服务。但业务一旦复杂起来，这招根本堵不住。优惠券、积分、物流、清结算，不同领域的数据天然分布在不同的服务里，你不可能把所有表都塞进一个库里。只要数据分库，跨库事务就是必然的课题。

1.2 2PC的先天不足与Seata的思路

很多人最先想到的是经典的两阶段提交（2PC）。简单说，2PC 引入一个协调者，先让所有参与方执行事务并上报“我准备好了”（Prepare），全部准备完成后协调者再发“正式提交”（Commit），否则让所有人回滚。

理论很完美，实际用起来非常痛苦。2PC 在 Prepare 阶段会一直持有数据库资源锁，如果某个参与方迟迟不响应，整个事务就一直挂着，严重拖垮并发。再加上协调者是单点，一旦崩溃，所有参与者都卡在未知状态里，只能靠人工介入。所以传统 2PC 更适合数据库层面的 XA 协议，不太适合作为微服务之间跨网络调用的通用方案。

Seata 的思路其实是对 2PC 做了工程化改造：它不再要求所有参与者锁住资源到全局事务结束，而是尽量把事务的提交拆成两个阶段，一阶段先完成本地业务提交，二阶段再做分布式协调。根据分支事务的类型，Seata 提供 AT、TCC、SAGA、XA 等模式。这里面 AT 和 TCC 是日常用得最多的，也是我最想展开对比的两种模式。

2. Seata的三角色模型：全局事务如何进行编排

2.1 TC、TM、RM各管什么

理解 AT 和 TCC 之前，得先把 Seata 的全局事务模型吃透。Seata 把一次分布式事务中的参与者抽象成了三个角色：

• TC（Transaction Coordinator），事务协调者。它是一个独立部署的服务端，负责维护全局事务和分支事务的状态，驱动全局提交或全局回滚。
• TM（Transaction Manager），事务管理器。它一般嵌入在发起全局事务的应用里，负责向 TC 申请开启全局事务、提交全局事务、回滚全局事务。你在业务方法上加的 @GlobalTransactional 注解，作用就是让 TM 感知到这个方法是一个全局事务的发起入口。
• RM（Resource Manager），资源管理器。它也嵌入在应用里，管理分支事务对应的资源，比如某个数据源、某个远程接口。RM 会向 TC 注册分支事务，并上报分支执行结果。

举个例子：订单服务调用库存服务和账户服务，订单服务这边是 TM，库存服务和账户服务里各自有 RM。TM 发起全局事务后拿到一个全局事务编号 XID，XID 会通过 RPC 调用链一路传递下去。下游服务的 RM 在执行各自的本地事务时，会把本地事务注册为这个全局事务下的一个分支事务。最后 TM 决定提交或回滚，TC 再通知所有 RM 执行二阶段。

2.2 全局事务的生命周期管理

一次 Seata 全局事务的典型生命周期是这样的：TM 向 TC 申请开启全局事务，拿到 XID；所有参与方在处理业务时，RM 将分支事务注册进这个 XID 下，并记录各自的本地事务状态。接着业务调用链一路执行下去，如果最终都成功了，TM 请求 TC 提交全局事务；如果中间任何一步抛异常，TM 请求 TC 回滚全局事务。TC 根据全局事务状态和分支注册情况，分别向各 RM 下发 Commit 或 Rollback 指令。

这种设计最大的好处是把“全局事务状态”集中到了 TC，各参与方的 CPU 和数据库开销被压到最低。就算某一个分支事务所在的微服务崩溃了，TC 侧的状态依然还在，它可以通过重试机制继续推进全局事务。这也是 Seata“最终一致”能力的底层基础——状态集中管理 + 持久化 + 重试。

值得注意的是，XID 的传递不是自动发生的。在 Spring Cloud 或 Dubbo 环境里，Seata 通过拦截器和过滤器把 XID 塞进 RPC headers 里，你基本无感知。但如果你用了 MQ 异步解耦、或者自己封装了 RPC 调用方式，就得手动传递 XID，否则下游创建的本地事务不会被认为是这个全局事务的分支，这是很多人掉过的坑。

3. AT模式：自动补偿背后的设计细节

3.1 一阶段：写业务数据时顺手留下“后悔药”

AT 模式的核心卖点是“对业务代码侵入非常小”。你在一个方法上打上 @GlobalTransactional 注解，方法里正常写业务 SQL，Seata 会自动拦截数据源操作，帮你在写数据的同时记录前后镜像。

以一条更新语句为例。你执行 UPDATE product SET stock = stock - 1 WHERE id = 123，Seata 在真正执行这段 SQL 前后会各做一次查询：执行前查出这条记录的长相，叫前置镜像（beforeImage）；执行后查出更新完的样子，叫后置镜像（afterImage）。然后 Seata 会把这两个镜像快照和这条业务 SQL 信息一起写入一张名叫 undo_log 的表，并且这个写 undo_log 的操作和业务 SQL 是在同一个本地事务里提交的。

这就是 AT 模式“一阶段本地提交”的由来。业务数据被更新了，undo_log 也写好了，两者在一个本地事务里同时成功，不存在只写了一半的情况。之后本地事务直接提交，业务数据对外是可以被读到的，不需要像传统 2PC 那样一直锁到全局事务结束。所以 AT 模式的性能明显好于 XA 2PC，代价也不是没有，后面会提到全局锁和隔离级别的问题。

3.2 二阶段：全局锁、镜像数据与回滚逻辑

全局事务执行完毕后，如果一切正常，TC 会通知各分支事务执行 Commit。AT 模式的 Commit 阶段逻辑很简单，就是异步删除那些已经没有用的 undo_log 记录。因为业务数据已经提交了，不需要再做补偿。

但如果过程中任何一个分支事务出了错，TC 就会下发 Rollback。RM 收到回滚指令后，会读取分支事务对应的 undo_log，根据里面的 beforeImage 生成反向 UPDATE/DELETE 语句，反向执行把数据恢复原状。恢复之前还会对比当前数据和 afterImage 是否一致，防止这段时间里这个数据被其他事务改过。

这里有一个微妙但非常关键的机制叫“全局锁”。Seata 为了保证一个全局事务在回滚时，其他事务不会把同样的数据改来改去，在分支事务执行写操作时会向 TC 申请一把针对该主键的全局锁。如果锁申请不到（有另一个全局事务正在改同一行），这个分支事务就会一直重试等待，直到拿到锁或超时。这也意味着：即使各分支事务的本地事务都提交了，任何其他全局事务在修改同一行数据前，都先要拿全局锁，拿不到就等。这就是 AT 模式隔离性的底层支撑——不是靠数据库行锁，而是靠 TC 这把全局锁。

需要明确的是，AT 模式默认提供的是读已提交（RC）级别左右的隔离性，写与写之间通过全局锁互斥，读操作不做额外拦截。如果你有更严格的隔离要求，可以在查询语句上使用 SELECT ... FOR UPDATE，让查询也申请全局锁，相当于手动升级成可串行化隔离。

3.3 AT模式落地必须注意的约束

AT 模式看起来“无侵入”，实际落地时约束不少。最基础的是，每个业务数据库里都要建 undo_log 表，结构必须符合 Seata 的要求。这张表没有建好，或者建错了库（典型错误是建到了别的库），事务一跑就报错。

建表 SQL 大概是这样的：

CREATE TABLE `undo_log` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `branch_id` bigint(20) NOT NULL, `xid` varchar(100) 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`), UNIQUE KEY `ux_undo_log` (`xid`, `branch_id`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

还有几个容易踩的坑。第一，业务 SQL 不要用 TRUNCATE TABLE 这种没法被镜像机制捕捉的语句，它不会逐行生成前后镜像，回滚时就不知道要恢复什么。第二，一次 UPDATE 如果影响了几十万行，Seata 会生成超大镜像，undo_log 瞬时膨胀，网络和磁盘开销都很吓人，所以要控制单条 SQL 更新数据的规模，尽量拆分批次。第三，如果你在应用里又自己写了数据同步或批处理脚本直接操作同一个库，不被 Seata 代理，就可能出现全局锁之外的并发修改，导致镜像校验失败。

我在实际项目里见过最典型的“AT 坑”是：全局事务的回滚成功了，但业务数据表面看起来恢复了，实际上一些关联表的关联键在反向补偿之后出现偏移。原因往往是对同一张表同时存在多个分支更新，前置镜像之间互相覆盖。所以 AT 模式更适合“一分支一表少量数据变动”的场景，如果多个分支都在动同一批热点数据，后面要说的 TCC 或者对账机制会更踏实。

4. TCC模式：用多点业务编码换取精准控制

4.1 Try、Confirm、Cancel三个方法怎么分工

TCC 模式的英文全称是 Try-Confirm-Cancel，把一次业务操作拆成三个方法，业务方要自己实现这三个阶段的具体逻辑。Try 阶段负责资源的检查和预留，比如库存服务先冻结一部分库存，而不是直接扣减。Confirm 阶段把预留的资源真正使用掉，比如把冻结库存变成已扣减。Cancel 阶段释放 Try 阶段预留的资源，比如把冻结又释放回可用库存。

为什么要把“预留”和“使用”拆开？核心目的是避免传统 2PC 长期锁资源。Try 阶段只做轻量级的预占，资源状态明确，不需要行锁挂很久。等到全局事务确认要提交了，Confirm 阶段可以快速完成真实扣减。如果某个分支失败，Cancel 阶段把之前 Try 的预留全部释放，让系统回到操作前的状态，这个过程由业务代码自己保证，而不是依赖数据库的回滚机制。

一句话总结：AT 模式把补偿机制交给了框架自动生成的镜像快照，TCC 模式把补偿机制交给了业务自己写的 Cancel 方法。代价是侵入性强，但换来了更高的灵活性和性能可控性。

4.2 绕不开的空回滚、幂等与悬挂问题

TCC 模式不是“写三个方法就算完事”，它有几个非常精妙的工程问题必须处理，处理不好全局事务照样出乱子。

第一个是空回滚。如果 Try 阶段因为网络超时，请求根本没到达提供方，但全局事务已经判定失败，TC 照样会下发 Cancel 请求。这时 Cancel 执行的时候，Try 其实从来没跑过，业务上不能再去释放什么资源，否则会把别人的资源也释放掉。这种“没有 Try 过就去 Cancel”的情况必须识别出来，典型的做法是在 Try 和 Cancel 里都查一下冻结记录表存不存在，不存在就直接标记 Cancel 成功。

第二个是幂等。Confirm 和 Cancel 可能因为网络重试、TC 重发指令等被调用多次，必须保证重复调用不会产生副作用。很多团队用一张事务控制表来记录每个分支事务当前执行到了哪个阶段，接到重复请求时查状态直接返回。

第三个是悬挂。什么叫悬挂？就是 Cancel 比 Try 先到达了。这发生在 Try 请求在网络上超时很久，全局事务已经回滚，Cancel 都执行完了，Try 才晃晃悠悠到达服务端。如果这个时候 Try 再去预占资源，就白白预留了一笔没人处理的资源，永远悬挂在那。处理办法通常是记录分支事务状态，如果发现这个分支已被 Cancel，Try 要拒绝执行业务逻辑。

我建议所有做 TCC 的项目都配一张事务控制表，用来记录分支事务编号、Try/Confirm/Cancel 各自的状态、创建时间。这张表是整个 TCC 分支一致性的“锚点”，没有它，很多异常根本无法判断。表结构可以参考这样设计：

CREATE TABLE tcc_branch_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, xid VARCHAR(128) NOT NULL, branch_id BIGINT NOT NULL, try_status TINYINT DEFAULT NULL, confirm_status TINYINT DEFAULT NULL, cancel_status TINYINT DEFAULT NULL, create_time DATETIME NOT NULL, update_time DATETIME NOT NULL, UNIQUE KEY uk_xid_branch (xid, branch_id) );

4.3 TCC在Seata里的接入示例

以 Spring Boot + Seata 为例，TCC 模式的接入方式大致长这样。先写一个 TCC 接口，声明分支事务，定义 Confirm 和 Cancel 方法。代码逻辑上通常的做法是在一个普通 Service 里定义三个方法，然后用 Seata 的 @TwoPhaseBusinessAction 注解把三个方法绑定起来：

@Service public class InventoryTccService { @TwoPhaseBusinessAction(name = "inventoryTcc", commitMethod = "confirmDeduct", rollbackMethod = "cancelDeduct") public void tryDeduct(InventoryDTO dto, BusinessActionContext context) { // 1. 检查库存 // 2. 冻结库存：UPDATE inventory SET frozen = frozen + ? WHERE id = ? // 3. 记录冻结流水到 tcc_branch_log，标记 try_status } public void confirmDeduct(InventoryDTO dto, BusinessActionContext context) { // 1. 检查冻结记录 // 2. 扣减库存：UPDATE inventory SET stock = stock - ?, frozen = frozen - ? // 3. 更新分支日志 confirm_status } public void cancelDeduct(InventoryDTO dto, BusinessActionContext context) { // 1. 检查冻结记录，没有则说明 Try 未执行，处理空回滚 // 2. 释放冻结：UPDATE inventory SET frozen = frozen - ? // 3. 更新分支日志 cancel_status } }

BusinessActionContext 里携带了 XID、branchId 等上下文信息。需要注意的是别忽略幂等和空回滚逻辑，直接在 Confirm/Cancel 里写不检查状态的裸 SQL，上线一压测就会出问题。

TCC 的性能优势在 Try 阶段体现得很明显：预留资源操作往往只需要改一个“冻结”字段，走索引，锁范围小。不像 AT 模式在二阶段回滚时要解析镜像、逐行恢复，TCC 的 Cancel 方法由业务自己精准控制，可以选择单独更新某一行某个字段，性能天然更好。代价是开发和维护成本高，每接入一个新业务场景，都要设计和实现一套 Try/Confirm/Cancel，还要处理异常分支逻辑。

5. AT模式与TCC模式的实战对比

5.1 维度对比：从一致性到运维成本

聊完了机制细节，我把这两种模式放在一张表里做一个直观对比，方便你按项目情况对照选择。

如果你想用一句话总结选型逻辑：能接受“框架自动做补偿”的粗糙度，而且没什么高并发热点竞争，优先用 AT；如果你对一致性边界的要求是“必须进到业务代码里，明确每一笔资源什么时候预占、什么时候落定”，那 TCC 更可靠。

5.2 场景选型：什么时候用AT，什么时候用TCC

从我自己的实践来看，同一个系统里完全不排斥混合使用这两种模式。Seata 的一个全局事务里，不同参与方可以各自选择不同的事务模式，只要你注册的分支类型类型匹配就行。

举个例子，一个下单优惠券发放场景：订单表、优惠券表都是低频更新，用 AT 模式最省事，团队不用专门为这俩服务写一套 TCC 方法。但库存在高并发秒杀场景是热点数据，更新频繁、冲突率高，这时候还上 AT，全局锁很容易冲突，回滚时镜像校验也容易失败，所以库存服务这类就适合用 TCC 做“Try 冻结库存 + Cancel 解冻”的精细化控制。

我踩过的一次真实教训是：某次某个项目里库存用了 AT，压测到一定并发规模后，全局锁冲突比例直线上升，大量的分支事务卡在等全局锁，数据库连接池被打满，接口 RT 飙升。后来把库存分支改成 TCC，同时把锁持有时间压在 Try 阶段几十毫秒内，问题立刻缓解很多。从那以后，我对“热点数据、高竞争、强一致”这几个关键词就特别敏感，一律偏向 TCC。

另外要注意的一个点：不要把 AT 当成万能药。AT 虽然自动生成补偿 SQL，但遇到复杂的级联更新、存储过程、多表联动修改，它的镜像机制可能处理得不够精细，回滚时容易遗漏。如果你业务里的更新逻辑足够复杂，就果断选 TCC 或者考虑换 SAGA。

6. 一致性保障机制全解析

6.1 故障模型与最终一致性的边界

分布式事务的最终一致性，不是指“永远不保证”，而是指在一段时间内可能出现中间状态，但系统会在故障恢复后通过重试、补偿把数据收敛到正确状态。要理解一致性保障，先要理解故障模型：网络可能延迟、重复、乱序，服务可能崩溃，TC 可能重启，数据库可能宕机。任何一个环节出问题，全局事务都可能卡在半途。

Seata 的做法是引入持久化的全局事务状态。TC 服务端把全局事务记录保存在数据库里（还可以挂注册中心选主），每个分支事务也有状态记录。TM 发起事务后写入全局事务表；分支事务注册后写入分支事务表。一切状态落库，不依赖内存。所以就算 TC 进程挂掉，重启后仍然能根据全局事务表里的状态，继续推进未完成的事务。

6.2 守护一致性的三道防线

光有状态记录还不够，真正保证最终一致得靠三道防线。

第一道防线是二阶段的重试机制。全局事务在提交或回滚阶段如果遇到网络异常、某个 RM 不在线，TC 不会立刻把事务标记为失败，而是进入重试状态，再根据配置的时间间隔反复向该 RM 发送指令，直到事务收敛为止。这个重试对于 RM 端的接口是有要求的：必须幂等。比如 AT 模式删除 undo_log 的操作，TCC 的 Confirm/Cancel 方法，都要能保证重复执行不产生新问题。

第二道防线是全局锁和版本比对。AT 模式在回滚前用 afterImage 和当前数据做比对，就是为了防止“补偿 SQL 把别人已经成功提交的修改也覆盖掉”。一旦发现不一致，说明数据被并发改动，这时候宁可抛出异常、转人工干预，也不能盲目回滚。

第三道防线是业务层面的幂等与状态控制。TCC 场景下，幂等、空回滚、悬挂前面已经展开讲过了。它们本质上都是为了应对各种异常的网络时序，保证业务补偿不被重复执行、不凭空执行、不错序执行。可以说，TCC 项目写得好不好，就看这三条防线是不是真的都织起来了。

6.3 超时重试与全局事务状态机

Seata 全局事务有几个典型状态：Begin、Committing、CommitRetrying、Rollbacking、RollbackRetrying、AsyncCommitting、Timeout 等。从一个状态到另一个状态，由 TC 内部的事件驱动和定时任务驱动完成。

超时处理的逻辑值得讲一下。TM 开启全局事务时可以设置超时时间，默认值不够用的时候要主动调整。如果全局事务超过了这个时间还没结束，TC 会自动把它标记为 Rollbacking，然后驱动所有分支回滚。这个设计避免了一个卡死的事务永远占着全局锁不释放。

我见过一个特别坑的情况：分支服务的数据库连接池被耗尽了，分支事务一直没有返回，导致全局事务一直等，最后触发超时回滚。但回滚也要经过同一个卡死的连接池，于是陷入恶性循环。这种问题靠分布式事务中间件本身解决不了，你必须在源头控制每个分支的 RT，给分支调用设置合理的网络超时，别让一个慢接口拖死全局事务。

7. 常见问题与排查实践

7.1 全局锁冲突导致的大量等待

现象是压测时接口 RT 突增，日志里出现“Global lock acquire failed”之类的关键字，结合 TC 监控能看到全局锁冲突率偏高。排查思路先看集中在哪些主键、哪些表上，如果是热点账户、热点商品这种高竞争数据，建议把对应分支改成 TCC，把锁持有时间缩短；如果是某个 SQL 没走索引导致锁范围变大，优先优化 SQL。

Seata 客户端有一组锁重试参数可以调，比如锁重试次数、重试间隔。增大重试次数能让分支事务更耐心地等待全局锁，但也可能把超时时间拖长；调小又会提高拿不到锁直接失败的频率。这个参数没有万能值，我习惯按照业务接口的 P999 耗时来定。

7.2 undo_log异常与数据缺失

AT 模式最常见的诡异问题就是：全局事务回滚成功了，但数据还是不对。排查时第一件事打开对应的 undo_log 表，看看 rollback_info 里的 beforeImage 和 afterImage 是否符合预期。如果 afterImage 和当前数据对不上，说明在事务执行期间，数据被非全局事务或另一个分支给改了。再看看全局事务表 global_table 和分支表 branch_table，确认状态流转到哪一步、有没有重试记录。

还有一个高频问题：undo_log 表很大，磁盘和备库同步压力大。Seata 本身有清理已提交全局事务 undo_log 的能力，但如果你发现没清理，优先检查版本号和时间配置。同时业务上尽量别频繁大范围 UPDATE，镜像体量一大，这个表必然膨胀。

7.3 事务超时、悬挂边界与对账策略

如果分支服务之间调用链路很长，全局事务超过默认超时时间，会自动回滚，但分支侧可能还在跑业务逻辑。这种超时和悬挂边界，经常会引发“业务执行完但全局事务被判失败”的冲突。我建议在关键链路上主动设好 Seata 全局事务超时、Spring Cloud 或 Dubbo 的 RPC 超时、以及数据库连接超时三者之间的关系，让超时顺序形成梯度，而不是一锅乱炖。

更重要的一个习惯是：无论用了 AT 还是 TCC，线上都必须配对账任务。最基础的做法是在业务低峰期，按订单号或流水号把各服务里关联的数据做一遍一致性校验。比如用“本地消息表”记录每次分布式事务涉及的关联键，然后定时扫描比对各服务的最终状态。只有对账任务能把一些极端情况下的脏数据捞出来，靠中间件本身很难百分之百避免人工兜底。

用久了 Seata 之后，我个人的体会是：分布式事务方案没有银弹，AT 让你爽，也让你粗；TCC 让你累，但边界清晰。真正可靠的生产环境，是选对模式、配好超时、设计对账，再辅以监控告警。最后再分享一个小习惯：每次新接入一个分布式事务场景，我都会先把全局事务表、分支事务表、undo_log 表的关键字段监控和告警配好，再谈业务功能开发。状态可见，问题才可解。