Seata 整体架构与核心概念
Seata 是阿里巴巴开源的分布式事务解决方案，原名 Fescar，后改名 Seata（Simple Extensible Autonomous Transaction Architecture）。它提供 AT、TCC、SAGA、XA 四种模式，覆盖从强一致到最终一致的多种需求，是 Spring Cloud Alibaba 微服务体系中分布式事务的标准答案。
Seata 是什么
定位
Seata 解决的问题：
一次业务调用跨多个服务、多个数据库时，
保证所有数据变更"要么全部成功、要么全部回滚"。
与 2PC 的区别：
经典 2PC 在数据库层锁资源、阻塞事务
Seata 把事务管理下沉到中间件层，业务只需一个注解设计目标
| 目标 | 说明 |
|---|---|
| 对业务低侵入 | AT 模式只需加注解，SQL 由框架自动处理 |
| 多模式可选 | 强一致（XA）到最终一致（SAGA）全覆盖 |
| 高性能 | 相比传统 2PC 大幅减少资源锁持有时间 |
| 生态整合 | 与 Spring Cloud、Dubbo、Nacos、Consul 等无缝集成 |
三大核心组件
Seata 的事务模型由三个角色组成：
| 组件 | 全称 | 角色 | 部署位置 |
|---|---|---|---|
| TC | Transaction Coordinator | 事务协调者 | 独立部署（Seata Server） |
| TM | Transaction Manager | 事务管理器 | 业务应用内 |
| RM | Resource Manager | 资源管理器 | 业务应用内 |
TM（事务管理器，业务应用内）
│ 开启/提交/回滚全局事务
▼
TC（事务协调者，独立服务）
│ 管理全局事务状态
│ 协调各分支事务的二阶段
▼
RM（资源管理器，业务应用内，每个库一个）
│ 注册分支事务
│ 上报分支执行结果
▼
数据库（每个 RM 对应一个数据源）各组件职责
TC（Seata Server）：
├─ 管理全局事务的开启、提交、回滚
├─ 保存全局事务 / 分支事务的注册信息
├─ 驱动二阶段提交与回滚
└─ 高可用部署（集群 + Raft / DB 共享）
TM（事务管理器）：
├─ 业务入口通过 @GlobalTransactional 开启全局事务
├─ 向 TC 发起 begin（全局事务 XID 的生成）
├─ 业务成功 → commit；异常 → rollback
└─ XID 通过调用链传播（RPC 头 / MQ 消息头）
RM（资源管理器）：
├─ 拦截数据源操作（DataSourceProxy 代理）
├─ 向 TC 注册分支事务（拿到 branchId）
├─ 生成前后镜像、写 undo_log
└─ 接收 TC 的二阶段指令执行提交或回滚全局事务执行流程
一次全局事务从开启到结束的完整时序：
TM（业务 A） TC（Seata Server） RM（业务 A/B）
│ │ │
├── begin 全局事务 ──────────▶ │ 生成全局 XID │
│◀──── 返回 XID ────────────── │ │
│ │ │
├── 执行业务：写库A ──────────▶│◀── 注册分支事务（分支1）── │ RM-A 写 undo_log
├── 调用服务B（携带 XID）──────│ │
│ │ │
│ │◀── 注册分支事务（分支2）── │ RM-B 写 undo_log
│ │ │
├── 业务全部成功 → commit ────▶ │ 记录全局状态为提交中 │
│ ├── 通知分支1 提交 ────────▶ │ RM-A 删 undo_log
│ ├── 通知分支2 提交 ────────▶ │ RM-B 删 undo_log
│ │ │
├── 业务异常 → rollback ──────▶│ 记录全局状态为回滚中 │
│ ├── 通知分支1 回滚 ────────▶ │ RM-A 用镜像恢复
│ └── 通知分支2 回滚 ────────▶ │ RM-B 用镜像恢复XID 的传播
XID（全局事务 ID）是贯穿整个链路的标识，通过调用上下文传播：
RPC 调用（Dubbo / OpenFeign）：
通过 RPC 框架的隐式参数 / 请求头传递 XID
Seata 提供 Filter / Interceptor 自动注入与提取
消息队列：
通过消息头携带 XID，消费端取出后继续加入同一全局事务四种事务模式
Seata 支持四种模式，对应不同的一致性需求与侵入程度。
AT 模式（Automatic Transaction）
AT 模式是 Seata 的招牌，业务几乎无侵入：
原理：对业务 SQL 自动生成"前镜像 + 后镜像"
1. 执行业务 SQL 前：查询记录当前值 → 前镜像
2. 执行业务 SQL（框架拦截，本地事务内执行）
3. 查询记录新值 → 后镜像
4. 前/后镜像写入 undo_log 表（与业务同事务）
5. 向 TC 注册分支事务
回滚时：用前镜像还原数据，校验中间是否有并发修改（脏写检查）| 优点 | 缺点 |
|---|---|
| 业务侵入小，只需注解 | 依赖全局锁，高并发下性能有损耗 |
| SQL 自动处理 | 不适用复杂 SQL（如 join 多表、DDL） |
| 接入快 | 需要 undo_log 表 |
TCC 模式（Try-Confirm-Cancel）
业务自己实现 Try / Confirm / Cancel 三组接口：
Try ：预留资源（冻结）
Confirm ：确认（真正扣减）
Cancel ：补偿（释放冻结）| 优点 | 缺点 |
|---|---|
| 不锁资源，性能好 | 侵入大，每个接口写三套逻辑 |
| 可用在资金强管控场景 | 需处理空回滚、悬挂、幂等 |
SAGA 模式
面向长流程，把事务拆成步骤 + 补偿：
正向：T1 → T2 → T3
失败：T3 失败 → 补偿 C2 → 补偿 C1Seata 的 SAGA 采用编排式，用状态机定义整个流程，支持并发、分支、合并等复杂编排。
XA 模式
在数据库 XA 协议之上封装，直接利用数据库的强一致能力：
1. 分支注册：RM 向 TC 注册
2. 阶段一：执行 SQL，XA PREPARE（不提交）
3. 阶段二：TC 决定全局提交 → XA COMMIT / ROLLBACK| 优点 | 缺点 |
|---|---|
| 强一致，数据库原生保证 | 资源锁持有时间长，性能差 |
| 业务侵入极低 | 依赖数据库对 XA 的支持 |
四模式对比
| 对比项 | AT | TCC | SAGA | XA |
|---|---|---|---|---|
| 一致性 | 最终一致 | 较强 | 最终一致 | 强一致 |
| 业务侵入 | 低（注解） | 高（三接口） | 中（状态机） | 低 |
| 性能 | 中 | 高 | 高 | 低 |
| 依赖 | undo_log + 全局锁 | 无 | 无 | 数据库 XA |
| 适用场景 | 跨库快速接入 | 资金强管控 | 长流程编排 | 强一致、低并发 |
选型建议
资金核心、并发低 → XA
资金核心、并发高 → TCC
跨库快速接入、SQL 简单 → AT
多步骤长流程（预订、审批）→ SAGA事务边界与隔离
全局事务边界
@GlobalTransactional 注解标记的方法体 = 全局事务边界
├─ 入口：TM 向 TC 发起 begin
├─ 内部所有 RM 的分支操作都归属同一个全局事务
└─ 退出：方法正常返回 → commit；抛出异常 → rollbackAT 模式的隔离机制
写隔离：
分支事务提交前，全局锁（lock_table）防止其他事务修改同一行
读隔离：
默认读已提交，未提交分支的数据对全局外不可见
需要强读隔离时可开启 select for update + 全局锁与微服务生态的整合
整合矩阵：
├─ 注册中心：Nacos / Consul / Eureka / Zookeeper / etcd
├─ 配置中心：Nacos / Consul / Apollo / Zookeeper
├─ RPC 框架：Dubbo / Spring Cloud OpenFeign / gRPC
├─ 数据源：支持 JDBC 的一切数据库（MySQL / PostgreSQL / Oracle / TiDB）
└─ 消息队列：RocketMQ / Kafka 等（通过 XID 传播参与事务）总结
Seata 用 TC / TM / RM 三组件 把分布式事务的协调逻辑从业务中剥离，用 四种模式 覆盖从强一致到最终一致的完整谱系：AT 模式低侵入、TCC 模式高性能、SAGA 模式适合长流程、XA 模式最省心但性能受限。理解三组件如何协作、四种模式各自的取舍，是落地 Seata 的第一步。