在微服务架构中，分布式事务是绕不开的难题。当 Spring Boot 4 遇上 Java 25，如何优雅地管理跨服务数据一致性？本文为你拆解 Seata 四大模式（AT、TCC、Saga、XA）与 Spring JDBC 事务的核心区别，并给出实战选型建议。

一、Seata 核心概念：三大角色与全局事务生命周期

Seata 的架构由 1 个 Server 端（TC） 和 2 个 Client 端（TM、RM） 组成。TC 负责协调全局事务，TM 负责开启/提交/回滚，RM 负责管理分支事务。全局事务的“身份证”是 XID，它通过 RPC 调用在下游服务间传递。

一个典型的全局事务生命周期如下：

  1. 开启全局事务：TM 向 TC 申请 XID。
  2. XID 传播：通过线程上下文和请求头透传。
  3. 分支注册：RM 在执行 SQL 前向 TC 注册分支事务。
  4. 本地事务执行：AT 模式生成 undo_log，TCC 模式执行 Try。
  5. 全局决议：TM 通知 TC 提交或回滚所有分支。

关键点：全局事务的生命周期是理解 Seata 的基础，所有模式都遵循这一框架。

角色全称定位核心职责
TCTransaction Coordinator
(事务协调者)		Server 端
(独立部署)		维护全局事务和分支事务的状态；
驱动全局提交或回滚；
管理全局锁。
TMTransaction Manager
(事务管理器)		Client 端
(代码注解)		定义全局事务的边界（开启、提交、回滚）；
通常由业务服务中的 注解实现。
开始全局事务、提交或回滚全局事务。
RMResource Manager
(资源管理器)		Client 端
(数据源代理)		管理分支事务处理的资源
与TC通信以注册分支事务和报告分支事务的状态
驱动分支事务提交或回滚。

二、Spring JDBC 事务 vs Seata 分布式事务

Spring JDBC 事务（本地事务）局限于 单 JVM 和单数据库，依赖数据库自身的 ACID。而 Seata 分布式事务跨越 多个微服务和数据库实例，通过独立中间件实现一致性。

对比核心差异：

  • 实现原理：Spring JDBC 基于 AOP 代理，Seata AT 基于两阶段提交 + undo_log。
  • 数据一致性：Spring JDBC 提供强一致性，Seata AT 提供最终一致性。
  • 隔离性：Spring JDBC 依赖数据库锁，Seata 依赖全局锁。
  • 代码侵入性：Spring JDBC 只需 @Transactional，Seata 需配置数据源代理和独立 Server。

⚠️ 注意：Seata 需要处理空回滚、悬挂、幂等这些分布式特有的异常场景。

维度Spring JDBC 事务Seata 事务 (AT 模式)
本质数据库本地事务的封装分布式事务协调器
核心机制JDBC Connection + 数据库锁两阶段提交 + Undo Log + 全局锁
一致性强一致性 (ACID)最终一致性
回滚方式数据库 Undo Log 物理回滚应用层反向 SQL 补偿
注解 (入口)
配置组件 + +
适用场景单体应用、单数据库微服务跨服务、跨数据库的微服务架构
一句话总结：
Spring JDBC 事务是“单兵作战”的武器，管好自己连接的那一个数据库；
Seata 是“联合作战”的指挥官，协调多个 Spring JDBC 事务（或其他资源）共同进退。

三、Seata 四大模式：AT、TCC、Saga、XA 详解

Seata 的四种模式在 代码侵入性、一致性强度、性能 上各有侧重。下面逐一拆解。

1. AT 模式（Automatic Transaction）

定位：默认推荐，对业务无侵入。通过数据源代理自动生成 undo_log（包含修改前后镜像），一阶段提交业务数据和回滚日志，二阶段异步删除或反向回滚。

✅ 优点：开发几乎零改动。❌ 缺点：依赖数据库，undo_log 表有轻微性能损耗。

-- for AT mode you must to init this sql for you business database. the seata server not need it.
CREATE TABLE IF NOT EXISTS `undo_log`
(
`branch_id`     BIGINT       NOT NULL COMMENT 'branch transaction id',
`xid`           VARCHAR(128) NOT NULL COMMENT 'global transaction id',
`context`       VARCHAR(128) NOT NULL COMMENT 'undo_log context,such as serialization',
`rollback_info` LONGBLOB     NOT NULL COMMENT 'rollback info',
`log_status`    INT(11)      NOT NULL COMMENT '0:normal status,1:defense status',
`log_created`   DATETIME(6)  NOT NULL COMMENT 'create datetime',
`log_modified`  DATETIME(6)  NOT NULL COMMENT 'modify datetime',
UNIQUE KEY `ux_undo_log` (`xid`, `branch_id`)
) ENGINE = InnoDB AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8mb4 COMMENT ='AT transaction mode undo table';
ALTER TABLE `undo_log` ADD INDEX `ix_log_created` (`log_created`);

2. TCC 模式（Try-Confirm-Cancel）

定位：高性能、业务自定义。开发者手动实现 Try（预留资源）、Confirm（确认提交）、Cancel（释放资源）三步。

✅ 优点：性能极高，支持非数据库资源（如 Redis、MQ）。❌ 缺点：代码侵入性强，需处理幂等、空回滚、悬挂三大难题。

CREATE TABLE IF NOT EXISTS `tcc_fence_log`
(
`xid`           VARCHAR(128)  NOT NULL COMMENT 'global id',
`branch_id`     BIGINT        NOT NULL COMMENT 'branch id',
`action_name`   VARCHAR(64)   NOT NULL COMMENT 'action name',
`status`        TINYINT       NOT NULL COMMENT 'status(tried:1;committed:2;rollbacked:3;suspended:4)',
`gmt_create`    DATETIME(3)   NOT NULL COMMENT 'create time',
`gmt_modified`  DATETIME(3)   NOT NULL COMMENT 'update time',
PRIMARY KEY (`xid`, `branch_id`),
KEY `idx_gmt_modified` (`gmt_modified`),
KEY `idx_status` (`status`)
) ENGINE = InnoDB
DEFAULT CHARSET = utf8mb4;

3. SAGA 模式

定位：长事务解决方案。将大事务拆分为多个本地事务，失败时按相反顺序执行补偿操作。

✅ 优点：服务间解耦，适合分钟级到天级的业务。❌ 缺点：回滚时中间状态可能被读取（弱一致性）。

4. XA 模式

定位：传统强一致性。基于标准 XA 协议，一阶段不提交（持有锁），二阶段统一提交或回滚。

✅ 优点：强一致性（ACID）。❌ 缺点：性能差，锁持有时间长。

特性AT 模式 (默认推荐)TCC 模式SAGA 模式XA 模式
代码侵入性无侵入 (仅注解)高侵入 (需写3个接口)中侵入 (需写补偿逻辑)无侵入 (仅注解)
一致性最终一致性最终一致性最终一致性强一致性
性能⭐⭐⭐⭐ (一阶段提交)⭐⭐⭐⭐ (无数据库锁)⭐⭐⭐ (长流程)⭐ (锁持有到第二阶段)
实现原理两阶段 + 自动生成回滚日志两阶段 + 手动预留/确认/取消长事务 + 补偿回滚两阶段提交协议
适用场景通用微服务 (CRUD)复杂业务/非数据库资源长流程/异步化业务金融核心/强一致要求

四、TCC 模式下的“三座大山”：空回滚、悬挂、幂等

网络不稳定（超时、重传、乱序）是 TCC 的噩梦。Seata 1.5.1+ 引入 tcc_fence_log 表，在框架层面统一解决。

  • 空回滚：Cancel 比 Try 先到。Seata 查 tcc_fence_log 表，若无 Try 记录则直接返回成功，避免资损。
  • 悬挂：Cancel 执行后 Try 才到。Seata 标记状态为 SUSPENDED，阻止 Try 执行。
  • 幂等：重复提交或回滚。Seata 通过状态机控制，确保同一操作只执行一次。

一句话总结：一张 tcc_fence_log 表，搞定所有网络异常问题。

TCC Fence

五、AT + TCC 混合使用：场景与坑

在复杂微服务系统中，单一模式往往不够。例如电商下单：扣库存用 AT（自动回滚），删购物车用 TCC（高性能），加积分用 SAGA（长流程）。

但混合使用要小心三个坑：

  1. 全局锁与业务锁的死锁：AT 持有全局锁，TCC 可能持有业务锁，两者相互等待导致死锁。
  2. 回滚机制不一致：AT 通过 undo_log 回滚，TCC 通过 Cancel 补偿，开发者容易误判一致性。
  3. 超时与悬挂复杂性：混合模式下超时和悬挂的处理逻辑更复杂。

✅ 建议：优先用 AT，性能瓶颈时混用 TCC，长流程用 SAGA，金融级用 XA。

[AFFILIATE_SLOT_1]

六、SAGA 模式实战：选型决策树

SAGA 适合 跨系统长周期业务（如订单履约、物流调度）和 涉及大量非数据库资源（如调用外部 API）的场景。它通过状态机定义流程和补偿逻辑，服务间解耦性极强。

选型决策树：

  • 业务是标准 CRUD + 关系型数据库 ➜ AT 模式
  • 并发极高 + 非数据库资源 ➜ TCC 模式
  • 业务流程长 + 异步执行 ➜ SAGA 模式
  • 金融级强一致 + 可接受性能损失 ➜ XA 模式

核心原则：没有银弹，根据业务场景灵活组合。

[AFFILIATE_SLOT_2]

总结

在 Spring Boot 4 和 Java 25 的微服务架构中，Seata 提供了 AT、TCC、Saga、XA 四种事务模式，与 Spring JDBC 本地事务形成互补。AT 模式是首选（零侵入），TCC 用于高性能场景，Saga 处理长流程，XA 提供强一致。根据业务场景灵活选型，才能实现 一致性、性能、开发效率 的平衡。

@GlobalTransactional@Transactional@GlobalTransactionalDataSourceDataSourceTransactionManagerDataSourceProxySeata Server