Seata分布式事务原理及优势解析
Seata分布式事务原理及优势解析
在微服务架构中，各服务往往独立部署、独立数据库，涉及到一个业务场景时，可能需要多个服务/多个数据库的写操作，这就引出了“分布式事务”的概念。Seata（Simple Extensible Autonomous Transaction Architecture）是阿里巴巴开源的一套易于集成、高性能、可插拔的分布式事务解决方案。本文将深入剖析 Seata 的分布式事务原理、核心架构、典型流程，并配以代码示例和图解，帮助读者快速掌握 Seata 的使用及其技术优势。
目录
- 为什么需要分布式事务
- Seata简介与核心组件
- Seata架构与典型流程
3.1. Seata 核心组件图解
3.2. 事务发起与分支注册流程
3.3. 分支执行与提交/回滚流程 - Seata 事务模式：AT 模式原理详解
4.1. AT 模式的 Undo Log 机制
4.2. 一阶段提交 (1PC) 与二阶段提交 (2PC)
4.3. AT 模式的完整流程图解 - Seata 与 Spring Boot 集成示例
5.1. 环境准备与依赖
5.2. Seata 配置文件示例
5.3. 代码示例：@GlobalTransactional与业务代码
5.4. RM（Resource Manager）配置与 Undo Log 表 - Seata的优势与使用注意事项
6.1. 相比传统 2PC 的性能优势
6.2. 轻量级易集成、支持多种事务模型
6.3. 异常自动恢复与可观测性
6.4. 注意谨慎场景与性能调优建议 - 总结
1. 为什么需要分布式事务
在单体应用中，数据库事务（ACID）可以保证在同一数据库的一系列操作要么全部成功、要么全部回滚。然而在微服务架构下，一个完整业务往往涉及多个服务，各自管理不同的数据源：
场景举例：
- 用户下单服务（OrderService）需要写
orders表； - 库存服务（StockService）需要扣减
stock表； - 支付服务（PaymentService）需要写
payments表； - 可能还需要写日志、写配送信息等。
- 用户下单服务（OrderService）需要写
如果我们仅靠单库事务，无法跨服务保证一致性。比如在扣减库存之后，支付失败了，库存和订单就会出现不一致。这种场景就需要分布式事务来保证以下特性：
- 原子性：多个服务/多个数据库的写操作要么都完成，要么都不生效。
- 一致性：业务最终状态一致。
- 隔离性：同一全局事务的并发执行对彼此保持隔离。
- 持久性：事务提交后的数据在持久化层不会丢失。
Seata 正是为解决这类跨服务、跨数据库的事务一致性问题而设计的。
2. Seata简介与核心组件
Seata 是一个分布式事务解决方案，致力于提供高性能、易用、强一致性保障。其核心组件包括：
TC（Transaction Coordinator）事务协调器
- 负责维护全局事务（Global Transaction）状态（Begin → Commit/Rollback）
- 为每个全局事务生成全局唯一 ID（XID）
- 协同各分支事务（Branch）完成提交或回滚
- 典型实现为独立进程，通过 gRPC/HTTP 与业务侧 TM 通信
TM（Transaction Manager）事务管理器
- 集成在业务应用（如 Spring Boot 服务）中
- 通过
@GlobalTransactional标注的方法开启全局事务（发送Begin请求给 TC） - 在执行本地业务方法时，为所依赖的数据库操作注册分支事务，发送
BranchRegister给 TC
RM（Resource Manager）资源管理器
- 代理并拦截实际数据库连接（使用 DataSourceProxy 或 MyBatis 拦截器）
- 在每个分支事务中，本地 SQL 执行前后插入 Undo Log，用于回滚时恢复
- 当 TC 通知全局提交/回滚时，向数据库提交或回滚相应的分支
以下是 Seata 核心组件的简化架构图解：
┌───────────────────────────────────────────────────────────────────┐
│ 业务微服务 (Spring Boot) │
│ ┌──────────────┐ ┌───────────────┐ ┌───────────────┐ │
│ │ TM 客户端 │ │ TM 客户端 │ │ TM 客户端 │ │
│ │ (事务管理) │ │ (事务管理) │ │ (事务管理) │ │
│ └──────┬───────┘ └──────┬────────┘ └──────┬────────┘ │
│ │ │ │ │
│ │ GlobalBegin │ GlobalBegin │ │
│ ▼ ▼ ▼ │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ Transaction Coordinator (TC) │ │
│ └───────────────────────────────────────────┬───────────────┘ │
│ BranchCommit/BranchRollback │ │
│ ◄────────────────────────────────────────┘ │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ RM 实现 │ │ RM 实现 │ │ RM 实现 │ │
│ │ (DataSourceProxy)│ │ (MyBatis 拦截器) │ │ (RocketMQ 模块) │ │
│ └──────┬───────┘ └──────┬────────┘ └──────┬────────┘ │
│ │ │ │ │
│ │ 本地数据库操作 │ 本地队列写入 │ │
│ ▼ ▼ ▼ │
│ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ │
│ │ DB (MySQL) │ │ DB (Postgre) │ │ MQ (RocketMQ) │ │
│ │ Undo Log │ │ Undo Log │ │ 本地事务 │ │
│ └────────────────┘ └────────────────┘ └────────────────┘ │
└───────────────────────────────────────────────────────────────────┘- TM：负责全局事务的开启/提交/回滚，向 TC 发起全局事务请求。
- TC：充当协调者，维护全局事务状态，等待分支事务上报执行结果后，再统一 Commit/Rollback。
- RM：在业务侧为每个分支事务生成并保存 Undo Log，当 TC 通知回滚时，根据 Undo Log 执行反向操作。
3. Seata架构与典型流程
3.1. Seata 核心组件图解
┌───────────────────────────────────────────────────────────────────┐
│ Global Transaction │
│ ┌──────────────┐ 1. Begin ┌──────────────┐ 2. BranchRegister │
│ │ TM 客户端 ├─────────▶│ TC ├──────────────────────┐ │
│ │(业务应用 A) │ └───┬──────────┘ │ │
│ └──────────────┘ ◀──────────┴──────────┐ │ │
│ │ │ │ │
│ │ 3. BranchCommit/BranchRollback │ │ │
│ ▼ │ │ │
│ ┌──────────────┐ │ │ │
│ │ RM 模块 │ │ │ │
│ │ (DB Proxy) │ │ │ │
│ └──────┬───────┘ │ │ │
│ │ 4. 本地事务执行 & Undo Log 记录 │ │ │
│ ▼ │ │ │
│ ┌───────────┐ │ │ │
│ │ DB (MySQL)│ │ │ │
│ └───────────┘ │ │ │
│ │ │ │
│ ┌──────────────┐ 1. Begin ┌──────────────┐ 2. BranchRegister │ │
│ │ TM 客户端 ├─────────▶│ TC ├──────────────────────┘ │
│ │(业务应用 B) │ └───┬──────────┘ │ │
│ └──────────────┘ ◀──────────┴──────────┐ │ │
│ │ │ │ │
│ │ 3. BranchCommit/BranchRollback │ │ │
│ ▼ │ │ │
│ ┌──────────────┐ │ │ │
│ │ RM 模块 │ │ │ │
│ │ (DB Proxy) │ │ │ │
│ └──────┬───────┘ │ │ │
│ │ 4. 本地事务执行 & Undo Log 记录 │ │ │
│ ▼ │ │ │
│ ┌───────────┐ │ │ │
│ │ DB (MySQL)│ │ │ │
│ └───────────┘ │ │ │
└───────────────────────────────────────────────────────────────────┘全局事务开始（GlobalBegin）
- TM 客户端（业务方法被
@GlobalTransactional标注）向 TC 发送GlobalBegin请求，TC 返回一个全局事务 ID（XID）。
- TM 客户端（业务方法被
分支注册（BranchRegister）
- 客户端在执行业务操作时（如第一家服务写入订单表），RM 模块拦截 SQL，并向 TC 发送
BranchRegister注册分支事务，TC 记录该分支事务 ID（Branch ID）。
- 客户端在执行业务操作时（如第一家服务写入订单表），RM 模块拦截 SQL，并向 TC 发送
分支执行（Local Transaction）
- RM 拦截器执行本地数据库事务，并写入 Undo Log。完成后向 TC 汇报
BranchCommit（若成功）或BranchRollback（若失败）。
- RM 拦截器执行本地数据库事务，并写入 Undo Log。完成后向 TC 汇报
全局事务提交/回滚（GlobalCommit/GlobalRollback）
- 当业务方法执行完成，TM 客户端向 TC 发送
GlobalCommit或GlobalRollback。 - 若
GlobalCommit：TC 收集所有分支事务状态，只要所有分支都返回成功，TC 向各分支 RM 发送BranchCommit，各 RM 执行本地提交（二阶段提交协议的第二阶段）； - 若
GlobalRollback：TC 向各分支 RM 发送BranchRollback，RM 根据之前保存的 Undo Log 执行回滚。
- 当业务方法执行完成，TM 客户端向 TC 发送
3.2. 事务发起与分支注册流程
下面详细说明一次简单的两阶段提交流程（AT 模式）。
3.2.1 全局事务发起
业务A 的 Service 方法（被 @GlobalTransactional 注解）
│
│ GlobalBegin(XID) ───────────────────────────────────────────▶ TC
│ (生成 XID)
│ ◀───────────────────────────────────────────────────────────
│ 继续执行业务逻辑- TM 客户端调用
GlobalBegin，TC 生成唯一 XID（如：127.0.0.1:8091:24358583）并返回。
3.2.2 分支事务注册
业务A 的 Service 调用 DAO 操作数据库
│
│ RM 拦截到 SQL（如 INSERT INTO orders ...）
│
│ BranchRegister(XID, ResourceID, LockKeys) ────────────────▶ TC
│ (注册 "创建订单" 分支) 执行 SQL 并插入 Undo Log
│ ◀───────────────────────────────────────────────────────────
│ 本地事务提交，向 TM 返回成功- RM 根据 DataSourceProxy 拦截到 SQL，先向 TC 发送分支注册请求，TC 返回一个 Branch ID。
- RM 在本地数据库执行 SQL，并保存 Undo Log（插入或更新前的旧值）。
- 完成本地提交后，RM 向 TC 报告分支提交 (
BranchCommit)，TC 对该分支标记“已就绪提交”。
3.3. 分支执行与提交/回滚流程
当全局事务中所有分支注册并就绪后，最终提交或回滚流程如下：
↑ ▲
│ │ BranchCommit/BranchRollback
┌─────────────────┐ │ │
│ TM 客户端调用 │ │ │
│ GlobalCommit │───┼───────┘
└───────┬─────────┘ │
│ │
│ GlobalCommit
▼ │
┌─────────────────────────┐
│ TC 判断所有分支已就绪， │
│ 广播 Commit 请求给每个分支 RM │
└────────────┬────────────┘
│
┌─────────▼─────────┐
│ RM1 (Resource) │
│ 收到 BranchCommit │
│ 执行本地事务提交 │
└─────────┬─────────┘
│
┌─────────▼─────────┐
│ RM2 (Resource) │
│ 收到 BranchCommit │
│ 执行本地事务提交 │
└─────────┬─────────┘
│
… 其他分支 … - 全局提交阶段：TC 依次向每个分支 RM 发送
BranchCommit； - RM 提交：各 RM 根据之前的 Undo Log，在本地完成真正的提交；
- 回滚流程（若有分支失败或业务抛异常）：TC 向所有分支发送
BranchRollback，各 RM 根据 Undo Log 回滚本地操作。
4. Seata 事务模式：AT 模式原理详解
Seata 支持多种事务模型（AT、TCC、SAGA、XA 等），其中最常用也是最简单易用的是 AT（Automatic Transaction）模式。它无需业务端显式编写 Try/Confirm/Cancel 方法，而是通过拦截 ORM 框架的 SQL，将原子操作记录到 Undo Log，从而实现对分支事务的回滚。
4.1. AT 模式的 Undo Log 机制
- Undo Log 作用：在每个分支事务执行之前，RM 会根据 SQL 拦截到 Before-Image（旧值），并在本地数据库的
undo_log表中插入一行 Undo Log，记录更新/删除前的旧数据库状态。 Undo Log 格式示例（MySQL 表）：
id branch\_id rollback\_info log\_status log\_created log\_modified 1 24358583-1 {"table":"orders","pk":"order\_id=1", "before":{"status":"0",...}} 0 2021-01-01 2021-01-01 Undo Log 内容说明：
branch_id：分支事务 ID，对应一次分支注册。rollback_info：序列化后的 JSON/YAML 格式，包含要回滚的表名、主键条件以及 Before-Image 数据。log_status：标识该 Undo Log 的状态（0：未回滚，1：已回滚）。
写入时机：当 RM 拦截到
UPDATE orders SET status=‘1’ WHERE order_id=1时，先执行类似：INSERT INTO undo_log(branch_id, rollback_info, log_status, log_created, log_modified) VALUES(24358583-1, '{"table":"orders","pk":"order_id=1","before":{"status":"0"}}', 0, NOW(), NOW())然后再执行：
UPDATE orders SET status='1' WHERE order_id=1;回滚时机：如果全局事务需要回滚，TC 会向 RM 发送回滚请求，RM 按
undo_log中的rollback_info逐条执行以下回滚 SQL：UPDATE orders SET status='0' WHERE order_id=1; UPDATE undo_log SET log_status=1 WHERE id=1;
4.2. 一阶段提交 (1PC) 与二阶段提交 (2PC)
二阶段提交流程（Two-Phase Commit）：
- 阶段1（Prepare 阶段）：各分支事务执行本地事务，并告知 TC “准备就绪”（仅写 Undo Log，不提交）；
- 阶段2（Commit/Rollback 阶段）：TC 收到所有分支就绪后，广播 Commit/Rollback。若 Commit，各分支提交本地事务；若回滚，各分支读 Undo Log 进行回滚。
Seata AT 模式实际上是一种改良版的 2PC：
- 阶段1：在分支执行前，先写 Undo Log（相当于 Prepare），然后执行本地 UPDATE/DELETE/INSERT，最后提交该分支本地事务；
- 阶段2：当 TC 通知 Commit 时，分支无需任何操作（因为本地已提交）；当 TC 通知 Rollback 时，各分支读取 Undo Log 执行回滚。
- 由于本地事务已经提交，AT 模式减少了一次本地事务的提交等待，性能优于传统 2PC。
4.3. AT 模式的完整流程图解
┌────────────────────────────────────────────────────────────────┐
│ 全局事务 TM 客户端 │
│ @GlobalTransactional │
│ public void placeOrder() { │
│ orderService.createOrder(); // 分支1 │
│ stockService.deductStock(); // 分支2 │
│ paymentService.payOrder(); // 分支3 │
│ } │
└────────────────────────────────────────────────────────────────┘
│ │ │
1. Begin(XID) │ │ │
──────────────▶│ │ │
│ │ │
2. CreateOrder │ │ │
BranchRegister(XID) │ │
└────────────────▶│ │
Undo Log & Local SQL │
◀─────────────────┘ │
│
2. DeductStock │
BranchRegister(XID) │
└──────────────────▶│
Undo Log & Local SQL│
◀────────────────────┘
│
2. PayOrder
BranchRegister(XID)
└───────────────▶
Undo Log & Local SQL
◀───────────────┘
│
3. TM send GlobalCommit(XID) │
──────────────▶ │
│ │
4. TC 广播 Commit 通知 │
BranchCommit(XID, branchId) ──▶ RM1 │
(Undo Log 不生效)│
分支已本地提交 │
│
BranchCommit(XID, branchId) ──▶ RM2
(Undo Log 不生效)
分支已本地提交
│
BranchCommit(XID, branchId) ──▶ RM3
(Undo Log 不生效)
分支已本地提交
│
│ │
│ 全局事务结束 - 分支执行阶段：每个分支执行时已完成本地数据库提交，仅在本地保留 Undo Log；
- 全局提交阶段：TC 通知分支 Commit，各分支无需再做本地提交；
- 回滚流程：若有一个分支执行失败或 TM 主动回滚，TC 通知所有分支 Rollback，各 RM 读取 Undo Log 反向执行恢复。
5. Seata 与 Spring Boot 集成示例
下面演示如何在 Spring Boot 项目中快速集成 Seata，并使用 AT 模式 完成分布式事务。
5.1. 环境准备与依赖
准备环境
- JDK 1.8+
- Maven
- MySQL（用于存储业务表与 Seata 的 Undo Log 表）
- 已部署好的 Seata Server（TC），可以直接下载 Seata 二进制包并启动
Maven 依赖（在 Spring Boot
pom.xml中添加）：<dependencies> <!-- Spring Boot Starter --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter</artifactId> </dependency> <!-- Seata Spring Boot Starter --> <dependency> <groupId>io.seata</groupId> <artifactId>seata-spring-boot-starter</artifactId> <version>1.5.2</version> <!-- 根据最新版本替换 --> </dependency> <!-- MyBatis Spring Boot Starter（或 JPA、JdbcTemplate 根据实际） --> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.2.0</version> </dependency> <!-- MySQL 驱动 --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.25</version> </dependency> </dependencies>Seata Server（TC）配置
修改 Seata 解压目录下
conf/registry.conf中：registry { type = "file" file { name = "registry.conf" } }- 修改
conf/registry.conf，指定注册中心类型（若使用 Nacos、etcd、ZooKeeper 可相应调整）。 修改
conf/file.conf中service.vgroup-mapping，配置业务应用对应的事务分组名称（dataSource 属性）：vgroup_mapping.my_test_tx_group = "default"启动 Seata Server：
sh bin/seata-server.sh
5.2. Seata 配置文件示例
在 Spring Boot application.yml 中添加 Seata 相关配置：
spring:
application:
name: order-service
datasource:
# 使用 Seata 提供的 DataSourceProxy
driver-class-name: com.mysql.cj.jdbc.Driver
url: jdbc:mysql://localhost:3306/order_db?useUnicode=true&characterEncoding=utf-8&serverTimezone=UTC
username: root
password: 123456
# Seata 需要的属性
seata:
tx-service-group: my_test_tx_group # 与 file.conf 中 vgroup_mapping 的 key 一致
mybatis:
mapper-locations: classpath*:/mappers/**/*.xml
type-aliases-package: com.example.demo.model
# Seata 客户端配置
seata:
enabled: true
application-id: order-service
tx-service-group: my_test_tx_group
service:
vgroup-mapping:
my_test_tx_group: "default"
client:
rm:
retry-count: 5
rm-async-commit-buffer-limit: 10000
registry:
type: file
file:
name: registry.conf
config:
type: file
file:
name: file.conftx-service-group：全局事务分组名称，需要与 Seata Server 的配置文件中的vgroup_mapping对应。application-id：业务应用的唯一标识。registry与config：指定注册中心与配置中心类型及所在的文件路径。
5.3. 代码示例：@GlobalTransactional 与业务代码
主配置类
@SpringBootApplication @EnableTransactionManagement public class OrderServiceApplication { public static void main(String[] args) { SpringApplication.run(OrderServiceApplication.class, args); } }数据源代理
在 Spring Boot
DataSource配置中使用 Seata 的DataSourceProxy：@Configuration public class DataSourceProxyConfig { @Bean @ConfigurationProperties(prefix = "spring.datasource") public DataSource druidDataSource() { return new com.alibaba.druid.pool.DruidDataSource(); } @Bean("dataSource") public DataSource dataSourceProxy(DataSource druidDataSource) { // 包装为 Seata 的 DataSourceProxy return new io.seata.rm.datasource.DataSourceProxy(druidDataSource); } // MyBatis 配置 DataSource 为 DataSourceProxy @Bean public SqlSessionFactory sqlSessionFactory(DataSource dataSource) throws Exception { SqlSessionFactoryBean factoryBean = new SqlSessionFactoryBean(); factoryBean.setDataSource(dataSource); // 其他配置略... return factoryBean.getObject(); } }Undo Log 表
在业务数据库中，需要有 Seata 默认的 Undo Log 表：
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) NULL, `rollback_info` LONG BLOB 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_branch_xid` (`xid`,`branch_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;业务 Service 示例
@Service public class OrderService { @Autowired private OrderMapper orderMapper; @Autowired private StockFeignClient stockFeignClient; @Autowired private PaymentFeignClient paymentFeignClient; /** * 使用 @GlobalTransactional 标注开启全局分布式事务 */ @GlobalTransactional(name = "order-create-tx", rollbackFor = Exception.class) public void createOrder(Order order) { // 1. 保存订单表 orderMapper.insert(order); // 2. 扣减库存（远程调用库存服务） stockFeignClient.deduct(order.getProductId(), order.getQuantity()); // 3. 扣减余额（远程调用支付服务） paymentFeignClient.pay(order.getUserId(), order.getAmount()); } }- 当
createOrder方法开始时，Seata TM 会向 TC 发送GlobalBegin，获取 XID； - 在保存订单时，RM（DataSourceProxy）会拦截并向 TC 注册分支事务，写 Undo Log；
- 当调用库存和支付服务时，分别在远程服务中重复同样的流程（各自将本地数据库代理给 Seata ），注册分支并写 Undo Log；
- 方法最后若无异常，TM 向 TC 发送
GlobalCommit，TC 广播BranchCommit给各分支 RM； - 若中途抛异常，TM 会自动向 TC 发送
GlobalRollback，TC 广播BranchRollback，各 RM 根据 Undo Log 回滚本地数据。
- 当
6. Seata的优势与使用注意事项
6.1. 相比传统 2PC 的性能优势
- 传统 2PC：每个分支在 Prepare 阶段要预写数据并锁表/锁行，等待全局确认后再执行真实提交或回滚，会产生两次本地事务提交，性能较差。
- Seata AT 模式：只在分支中执行一次本地提交，并在本地保存 Undo Log，属于“改良版 2PC”，只有在全局回滚时才执行回滚操作，提交路径减少了一次阻塞点。
- 性能提升：由于减少一次本地事务提交，且将回滚逻辑延后，Seata AT 相较传统 2PC 性能有明显提升。
6.2. 轻量级易集成、支持多种事务模型
- Spring Boot 一行配置：通过添加
seata-spring-boot-starter、注解@GlobalTransactional，即可快速开启分布式事务。 - 支持多种事务模型：除 AT 模式外，还支持 TCC（Try-Confirm-Cancel）、SAGA、XA 等，满足不同业务粒度的一致性需求。
6.3. 异常自动恢复与可观测性
- 自动恢复：如果某个分支节点宕机，TC 会周期性扫描未完成的分支事务，触发重试或重新回滚。
- 可观测性：Seata 提供配置项可开启日志收集、监控指标，对事务的提交/回滚过程进行全链路追踪，便于排查问题。
6.4. 注意谨慎场景与性能调优建议
- 长事务慎用：AT 模式会长时间锁定行，若事务长时间挂起，可能导致热点行锁等待。
- Undo Log 表膨胀：高并发写入时，Undo Log 会快速增长，应及时清理或触发 GC。
- 数据库压力监控：由于 Seata 会多写 Undo Log 表，业务表写入压力会增加，需要做好数据库垂直或水平扩展规划。
- 网络延迟：TC 与 TM、RM 之间依赖网络通信，需保证网络可靠低延迟。
7. 总结
本文从分布式事务的需求出发，系统介绍了 Seata 的核心架构、AT 模式原理、Undo Log 机制、典型的两阶段提交流程，并通过 Spring Boot 集成示例演示了 Seata 的落地方案。Seata 通过在分支事务中“先提交本地、后统一提交或回滚” 的方式，相比传统 2PC，在性能和可用性上具有显著优势。同时，Seata 支持多种事务模型，并提供异步恢复、可观测性等特性，非常适合微服务架构下的跨服务、跨数据库一致性场景。
Seata 优势：
- 性能更优：AT 模式减少一次本地提交，降低事务开销；
- 易集成：Spring Boot 一键式接入；
- 支持多模型：AT、TCC、SAGA、XA；
- 自动恢复：TC 定期扫描分支状态并自动重试/补偿；
- 可观测性：事务日志、监控指标、调用链追踪。
在实际生产环境中，请结合业务场景（事务长度、并发压力、数据库类型等）合理选择 Seata 模式，做好数据库性能监控与合理分库分表，才能充分发挥 Seata 的优势，保障系统的高可用与数据一致性。
评论已关闭