什么是 Seata？

Seata (Simple Extensible Autonomous Transaction Architecture) 是一款开源的分布式事务解决方案。与传统的 XA 协议不同，Seata 提供了一套在应用层实现的分布式事务框架，致力于在微服务架构下提供高性能和简单易用的数据一致性服务。

它最早由阿里巴巴在 2019 年开源，设计目标是解决微服务架构下，跨数据库、跨服务的数据一致性问题。

Seata 的三大核心角色

Seata 的架构设计参考了 DTP 模型（Distributed Transaction Processing），但在实现上进行了微服务化的改造。无论使用哪种事务模式（AT/TCC/Saga/XA），其运行时架构都由以下三个角色组成：

1. TC (Transaction Coordinator) - 事务协调者

   • 角色定位： 服务端 (Server)。它是独立的中间件服务器，通常以集群方式独立部署。
   • 核心职责： 它负责维护全局事务和分支事务的运行状态（Status），并根据 TM 的指令，驱动全局事务进入提交或回滚阶段。

2. TM (Transaction Manager) - 事务管理器

   • 角色定位： 客户端 (Client SDK)。它作为 Jar 包嵌入在业务应用中，通常存在于发起全局事务的微服务里（即标注了 @GlobalTransactional 的服务）。
   • **核心职责：**它控制全局事务的边界，负责向 TC 发起开启全局事务（Begin）、提交全局事务（Commit）或回滚全局事务（Rollback）的指令。

3. RM (Resource Manager) - 资源管理器

   • 角色定位： 客户端 (Client SDK)。它也作为 Jar 包嵌入在业务应用中，通常包裹在数据库连接池（DataSource）或业务逻辑层中。
   • **核心职责：**它负责管理具体的分支资源（如 Database、MQ、Service）。它与 TC 保持长连接，负责注册分支事务，并接收 TC 的指令来完成本地事务的最终提交或回滚。

架构交互拓扑图

Seata 的核心设计原理：抽象的两阶段提交

Seata 之所以能兼容 AT、TCC、Saga 等多种模式，是因为它在底层架构上进行了一次高度抽象。Seata 将所有分布式事务模型都抽象为“两阶段提交”的逻辑模型：

这正是 Seata 设计的高明之处——解耦了“协调逻辑”与“执行逻辑”。

• 第一阶段 (Phase 1)：业务执行与资源预留

  • 业务侧执行本地事务（或业务逻辑）。
  • RM 拦截执行过程，向 TC 注册分支，并根据不同模式做不同的“资源预留”（例如 AT 模式记录 Undo Log，TCC 模式执行 Try 方法）。
  • 关键点：在 AT 模式下，第一阶段结束时，本地数据库事务已经提交了！这是 Seata 高性能的核心。

• 第二阶段 (Phase 2)：事务决议与最终收敛

  • TC 根据 TM 的决议（Commit 或 Rollback），向所有 RM 发起二阶段指令。
  • RM 收到指令后完成最终动作（例如 AT 模式删除 Undo Log 或执行回滚，TCC 模式执行 Confirm/Cancel）。

全局事务生命周期详解

理解了设计原理后，我们再看具体的生命周期，就会非常清晰：

1. TM 开启事务 (Begin)： TM 请求 TC 开启一个全局事务。TC 生成一个全局唯一的 XID。
2. XID 传播 (Propagate)： XID 通过微服务调用链路（RPC Header）传递到每一个涉及的服务节点。
3. RM 注册与执行 (Register & Execute)：
   • 下游服务的 RM 拦截到请求，解析出 XID。
   • RM 向 TC 注册一个分支事务（Branch Transaction），将其归属到该 XID 下。
   • RM 执行本地业务逻辑（Phase 1）。
4. TM 发起决议 (Decide)：
   • 如果所有微服务调用都成功，TM 向 TC 发起 Global Commit。
   • 如果任一环节抛出异常，TM 向 TC 发起 Global Rollback。
5. TC 驱动完成 (Drive)： TC 遍历该 XID 下的所有分支事务，通知对应的 RM 执行第二阶段逻辑（Phase 2）。

核心机制：事务上下文传播

Seata 能够“穿透”微服务边界的核心机制就是 XID 的传播。

• XID 是什么？ 全局事务的唯一身份证（格式通常为 ip:port:transactionId）。
• 载体： Seata 针对主流的 RPC 框架（Dubbo, Spring Cloud, gRPC, Sofa-RPC）都提供了自动适配的拦截器。
• 过程： 拦截器将 XID 注入到 RPC 请求的 Header 中（类似 HTTP Header）。下游服务的拦截器从 Header 中取出 XID，并将其绑定到当前的线程上下文（ThreadLocal）中，供 RM 使用。

Seata 的四种事务模式概览

基于上述的“通用两阶段架构”，Seata 提供了四种具体实现，以应对不同的业务权衡（Trade-off）：

Seata Server (TC) 的存储模式

TC 是有状态的，它需要持久化记录“哪个全局事务正在进行”、“包含哪些分支事务”。Seata 支持三种存储模式：

• file (单机模式)： 存放在本地文件。读写快，但无法组建集群，宕机可能丢数据。仅限测试。
• db (高可用模式)： 生产环境推荐。将会话数据存放在共享数据库（如 MySQL）中。多个 TC 节点无状态，通过争抢数据库锁来协作，天然支持高可用集群。
• redis (高性能模式)： 将会话数据存放在 Redis 中。性能优于 DB 模式，适合超高并发场景。

总结

Seata 的核心价值在于它提供了一个标准化的分布式事务协作平台。

• 架构上：它定义了 TM、RM、TC 的铁三角关系。
• 原理上：它抽象了通用的“两阶段提交”模型。

(下篇预告：Seata 分布式事务全解（二）：浅聊 AT 模式)
Seata 分布式事务全解（二）：浅聊 AT 模式