Apache Seata 介绍与选型指南

Apache Seata 2.6 分布式事务框架的定位、核心架构（TC/TM/RM 与 AT/TCC/SAGA/XA 四种模式）、功能特性与同类选型对比

Apache SeataSeata分布式事务Java2026/10/15

Apache Seata 介绍与选型指南

目标：讲清 Apache Seata 是什么、解决什么问题、由哪些角色组成、支持哪几种事务模式，以及在 2026 年当前版本（2.6.0）下的同类方案选型对比。本文所述版本特性均已在 Ubuntu 22.04 + JDK 17 环境安装 Apache Seata 2.6.0 实测验证（安装过程见《Ubuntu 22.04 安装 Apache Seata 2.6 指南》）。

一、环境信息

本文结论基于以下实测环境：

  • 操作系统：Ubuntu 22.04（x86_64）
  • Java：OpenJDK 17（seata-server 运行环境）
  • 组件版本：Apache Seata 2.6.0（孵化器项目，官方二进制包 apache-seata-2.6.0-incubating-bin.tar.gz，共 183MB）
  • 官方站点：https://seata.apache.org
  • 安装目录：/opt/seata/seata-server（TC 服务端）、/opt/seata/seata-namingserver（命名服务与控制台）
  • 配置文件：/opt/seata/seata-server/conf/application.yml
  • 默认端口：8091（TC 服务端口）、8081（namingserver 控制台，2.6.0 起控制台 UI 独立部署）
  • 存储后端：file（默认）/ MySQL（db 模式，实测建表 5 张：global_table、branch_table、lock_table、distributed_lock、vgroup_table）

二、软件概述

Apache Seata（Simple Extensible Autonomous Transaction Architecture，曾用名 Fescar，2023 年 11 月进入 Apache 孵化器）是一款开源的分布式事务解决方案，提供高性能且易于使用的分布式事务能力。它诞生的初衷是解决微服务架构下，一次业务操作跨越多个服务、多个数据库时，如何保证整体一致性的问题。

💡 技术拓展：为什么需要分布式事务——单机数据库靠本地事务（ACID）保证一致性；当一笔业务要同时写订单库、库存库、账户库等多个数据源时，本地事务无法跨越多个连接/实例，任何一环失败都会留下中间状态。分布式事务就是把这多个"本地事务"作为一个整体来提交或回滚的机制。Seata 的 AT 模式通过在业务库中记录前后镜像（undo_log）实现无侵入的自动补偿，是目前 Java 微服务体系内接入成本最低的方案。

Seata 的核心设计理念是：对业务无侵入（AT 模式下一个 @GlobalTransactional 注解即可）与高性能（一阶段本地提交即释放连接和锁，二阶段异步批量处理）。

三、核心架构

Seata 采用 TC / TM / RM 三个角色的经典分布式事务架构，三个角色之间通过 Netty 私有 RPC 协议通信（默认端口 8091）。

3.1 三大角色

角色全称职责部署形态
TCTransaction Coordinator（事务协调器）维护全局事务和分支事务的状态，驱动全局提交或回滚独立部署的 seata-server 进程
TMTransaction Manager（事务管理器）定义全局事务边界：开启、提交、回滚全局事务内嵌在业务应用中（client 依赖）
RMResource Manager（资源管理器）管理分支事务的资源，向 TC 注册分支并汇报分支状态内嵌在业务应用中（client 依赖）

一句话概括三者关系：TM 向 TC 申请开启一个全局事务并拿到全局事务 ID（XID），XID 随调用链传播；每个参与方的 RM 用 XID 向 TC 注册分支事务；TM 决定提交或回滚时，TC 驱动所有相关分支完成二阶段动作。

3.2 全局事务处理流程（AT 模式实测视角）

以一次"两个服务操作两个数据库"的场景为例，Seata AT 模式的完整时序如下：

TM(业务发起方)                    TC(seata-server)                RM(分支参与方)
    |--- 1.开启全局事务 ---------------->|                               |
    |<-- 返回 XID ----------------------|                               |
    |--- 2.业务调用(携带XID) ----------------------------------------->|
    |                                   |<-- 3.注册分支事务 -------------|
    |                                   |--- 4.返回 branchId ---------->|
    |                                   |   （RM 一阶段：写 undo_log + 本地提交 + 上报状态）
    |--- 5.提交/回滚全局事务 ----------->|                               |
    |                                   |--- 6.二阶段:提交(删undo_log)/回滚(按镜像还原)

在本次实测（见《Ubuntu 22.04 安装 Apache Seata 2.6 指南》第十章）中，单个数据源、两步 UPDATE、第二步抛异常的最小全局事务，TC 侧真实日志如下（节选）：

[GlobalBegin] begin new global transaction [172.23.0.2:8091:1135741007761358867]
receive msg[single]: BranchRegisterRequest{xid='...867', branchType=AT, resourceId='jdbc:mysql://seata-db:3306/seata_demo', lockKey='demo_account:1', ...}
Register branch successfully, xid = 172.23.0.2:8091:1135741007761358867, branchId = 1135741007761358869, resourceId = jdbc:mysql://seata-db:3306/seata_demo ,lockKeys = demo_account:1
[GlobalRollback] roll back global transaction successfully, xid = 172.23.0.2:8091:1135741007761358867

客户端回滚结果：

rollback status: Rollbacked

业务数据由分支执行后的 1500 恢复为事务前值 1000，undo_log 表由 1 行清理为 0 行，global_table 中的事务记录在回滚完成后被异步清理。

3.3 四种事务模式

Seata 提供四种互补的事务模式，同一套 TC 可以同时支撑多种模式：

模式一阶段行为二阶段行为侵入性隔离性适用场景
AT（auto transaction）代理 JDBC 数据源，解析 SQL、记录前后镜像写入 undo_log 后本地提交提交：异步删除 undo_log；回滚：按镜像逆向补偿无侵入（仅加注解）全局写隔离（TC 全局锁）大多数基于关系型数据库的业务
TCC（try-confirm-cancel）业务自己实现 Try（预留资源）Confirm（确认）或 Cancel（取消补偿）高（每个操作写三个方法）业务自行保证高性能、金融级一致性场景
SAGA状态机驱动的长事务，正向服务顺序执行失败时逆向执行补偿服务中（编写状态机 JSON/服务）最终一致长流程业务、跨企业编排
XA数据库 XA 协议，两阶段提交由数据库保证数据库原生提交/回滚无侵入强隔离（读未提交不可见）对隔离性要求极高、可接受性能损失的数据库

💡 技术拓展：AT 与 XA 的本质区别——AT 是"补偿型"（一阶段就提交本地事务，靠镜像回滚，锁粒度小、吞吐高，但存在全局锁下的写隔离窗口）；XA 是"资源强占型"（两阶段期间数据库一直持有行锁直至事务结束，隔离性强但并发性能差、且依赖数据库 XA 驱动）。国内互联网场景绝大多数选 AT，银行核心等强隔离场景选 XA。

3.4 高可用与集群支撑组件

2.6.0 发行包包含两个可部署单元（安装包解压后为 seata-server/ 与 seata-namingserver/ 两个目录）：

  • seata-server：TC 协调器本体。多节点集群时，会话与锁存储支持 db / redis / raft 三种共享方式（file 仅限单节点）；节点发现支持 nacos、eureka、redis、zk、consul、etcd3、sofa、seata（自研命名服务）八种注册中心。
  • seata-namingserver：2.x 新增的轻量命名服务，同时承载控制台 UI（登录后可查看全局事务、分支、锁、撤销会话等）。⚠️ 实测注意：2.6.0 的 seata-namingserver 编译目标为 Java 25（class 文件版本 69.0），用 JDK 17 启动会直接抛 UnsupportedClassVersionError，需要单独准备 JDK 25+；seata-server 本体在 JDK 8~17 均可运行，本次实测使用 JDK 17。

四、功能特性

  • 四模式统一接入：AT / TCC / SAGA / XA 共用一套 TC 与事务组配置，可按业务逐接口选择模式。
  • 对业务零侵入（AT）：@GlobalTransactional 注解 + 数据源自动代理，业务代码不感知回滚逻辑。
  • XID 链路传播：提供对 Dubbo、Spring Cloud OpenFeign、gRPC、Motan、RocketMQ 等的 XID 传递集成模块。
  • 多注册中心 / 多配置中心：注册中心 8 种（file/nacos/eureka/redis/zk/consul/etcd3/sofa/seata），配置中心 6 种（file/nacos/apollo/zk/consul/etcd3）。
  • 多种存储后端：file（单机）、db（MySQL 等关系库）、redis、raft（内嵌分布式 raft 模式，无需外部存储）。
  • 全局锁与防悬挂：TC 全局锁保证 AT 写隔离；TCC 模式支持防悬挂、空回滚、幂等控制。
  • 控制台可视化：namingserver 控制台查看全局事务列表、分支信息、全局锁、undo 日志等（2.6.0 需 JDK 25）。
  • 指标导出：内置 metrics 能力，可导出到 Prometheus（实测 2.6.0 默认关闭，配置 seata.metrics.exporter-type: prometheus 时需注意端口占用）。

五、适用场景与限制

5.1 适用场景

  • Spring Boot / Spring Cloud 微服务体系中，跨服务跨库的写操作需要整体一致（下单扣库存、转账、积分联动等）。
  • 已有 MySQL/PostgreSQL/Oracle 等关系型数据库，希望以最低改造成本获得分布式事务（AT 模式）。
  • 需要混合模式：核心资金流用 TCC 保证性能，外围流程用 AT/SAGA 兜底。

5.2 限制与注意

  • AT 模式依赖"每张参与表必须有主键"，且事务粒度不宜过大（undo_log 镜像与全局锁都会放大）。
  • seata-server 集群必须用 db / redis / raft 存储，file 存储仅支持单节点。
  • 2.6.0 的控制台（namingserver）运行需要 JDK 25+，与 server 本体的 JDK 要分开部署（实测结论）。
  • 官方发行包不内置 MySQL JDBC 驱动（db 模式启动会报 The driver {com.mysql.cj.jdbc.Driver} cannot be found in the path .../lib/jdbc，需自行下载放入，实测过程见安装指南常见问题）。
  • 项目处于 Apache 孵化器（Incubating）阶段，发行包与命名均带 incubating 标识，升级节奏较快，生产跟进官方 Release Note。

六、同类选型对比

分布式事务/最终一致性方案主流选型：

方案类型模式侵入性性能社区活跃度（2026）适用
Apache Seata 2.6分布式事务框架AT/TCC/SAGA/XA低（AT 注解）高（一阶段本地提交）高，Apache 孵化器活跃迭代Java 微服务体系首选
DTM（Go）分布式事务管理器SAGA/TC2/消息等低（HTTP/gRPC 接入）高高（Go 生态）Go/多语言技术栈
本地消息表 + MQ最终一致性消息事务中（业务建表+对账）高通用模式可接受最终一致、已有 MQ
RocketMQ 事务消息消息事务半消息+回查中高高事件驱动、削峰场景
XA（数据库原生）强一致两阶段XA低低（锁持有久）数据库内置强隔离小并发
ServiceComb Pack分布式事务协调TCC/SAGA中中低（维护放缓）已用 ServiceComb 体系

选型结论：Java 技术栈、关系型数据库、要求低侵入与较高吞吐——首选 Apache Seata（AT 模式）；多语言或事件驱动为主——考虑 DTM 或 RocketMQ 事务消息；极强隔离要求且并发不大——XA。

七、参考链接