Seata 深度解析：微服务分布式事务管理的实践指南

在微服务架构中，业务逻辑往往需要跨多个服务调用（如订单服务调用库存服务、支付服务），传统单机事务（ACID）无法覆盖分布式场景 ------ 若某一服务调用失败，极易导致 "部分服务执行成功、部分失败" 的数据不一致问题。Seata（Simple Extensible Autonomous Transaction Architecture）作为 Alibaba 开源的分布式事务解决方案，通过轻量级设计实现了 "分布式事务的简化与标准化"，已成为微服务生态中事务管理的核心工具。本文将从原理到实践，带你全面掌握 Seata 的使用与优化。

一、微服务事务痛点：为什么需要 Seata？

在深入 Seata 之前，先明确微服务分布式事务的核心挑战，理解 Seata 解决的核心问题。

1.1、分布式事务的本质：跨服务的数据一致性

微服务拆分后，数据存储也随之拆分（订单数据存订单库、库存数据存库存库），传统单机事务的 "原子性" 无法保证：

示例场景：电商下单流程

订单服务：创建订单（订单库插入数据）；

库存服务：扣减商品库存（库存库更新数据）；

支付服务：处理用户支付（支付库插入数据）。

若步骤 2 执行成功，步骤 3 执行失败，会导致 "库存已扣减但支付未完成" 的不一致状态。

1.2、传统解决方案的局限

开发者常用的 "补偿机制""消息队列最终一致性" 等方案存在明显不足：

补偿机制：需手动编写 "回滚逻辑"（如库存扣减失败后恢复库存），代码侵入性强，维护成本高；

消息队列最终一致性：仅适用于 "非实时性" 场景（如异步通知），无法满足下单、支付等实时一致性需求；

2PC/3PC 协议：传统分布式事务协议（如 XA）性能差、资源锁定时间长，不适合高并发微服务场景。

1.3、 Seata 的核心价值：简化分布式事务

Seata 通过 "统一事务模型 + 轻量级实现"，解决了传统方案的痛点：

低侵入性：基于注解（如@GlobalTransactional）实现事务管理，无需大量修改业务代码；

多模式支持：提供 AT、TCC、SAGA、TXC 四种事务模式，适配不同业务场景；

高性能：避免长时间资源锁定（如 AT 模式通过 "快照 + 异步回滚" 优化性能）；

生态兼容：无缝集成 Spring Cloud、Dubbo、Nacos、Redis 等主流微服务组件。

二、Seata 核心架构：3 大角色与事务流程

Seata 的分布式事务管理依赖 "TC、TM、RM" 三大核心角色，三者协同完成全局事务的创建、执行与提交 / 回滚。

2.1、三大核心角色定义

|------|-------------------------|-------------------------------------------------------|--------------------|
| 角色缩写 | 角色名称 | 核心职责 | 部署位置 |
| TC | Transaction Coordinator | 事务协调者：负责全局事务的创建、状态管理（提交 / 回滚）、分支事务的协调 | 独立部署的 Seata Server |
| TM | Transaction Manager | 事务管理器：发起全局事务（标记事务入口），向 TC 注册全局事务并请求提交 / 回滚 | 微服务中的事务发起者（如订单服务） |
| RM | Resource Manager | 资源管理器：管理分支事务（如库存扣减、订单创建），向 TC 注册分支事务，执行 TC 的提交 / 回滚指令 | 每个微服务（与数据库交互的服务） |

2.2、全局事务执行流程（4 步拆解）

以 "订单服务（TM）调用库存服务（RM）" 为例，Seata 全局事务的核心流程如下：

全局事务初始化（TM → TC）

订单服务（TM）执行@GlobalTransactional注解的方法时，向 TC 发送 "创建全局事务" 请求，TC 生成唯一的globalTransactionId（全局事务 ID），并返回给 TM。

分支事务注册（RM → TC）

订单服务（RM1）执行本地事务（创建订单），向 TC 注册 "分支事务 1"，并绑定globalTransactionId；
订单服务调用库存服务（RM2）时，通过 "事务上下文传播" 将globalTransactionId传递给库存服务，库存服务执行本地事务（扣减库存），向 TC 注册 "分支事务 2"。

全局事务状态确认（TM → TC）

若所有分支事务执行成功，TM 向 TC 发送 "全局提交" 请求；若任一分支事务失败（如库存不足导致扣减失败），TM 向 TC 发送 "全局回滚" 请求。

分支事务提交 / 回滚（TC → RM）

TC 收到 "全局提交" 请求后，向所有 RM 发送 "分支提交" 指令，RM 执行本地事务提交；

TC 收到 "全局回滚" 请求后，向所有 RM 发送 "分支回滚" 指令，RM 基于快照或预编译日志执行本地事务回滚。

2.3、事务上下文传播

Seata 通过 "ThreadLocal + 框架拦截器" 实现globalTransactionId的跨服务传播：

发起方（TM）：调用远程服务前，拦截器将globalTransactionId放入请求头（如 HTTP Header、Dubbo Attachment）；

接收方（RM）：收到请求后，拦截器从请求头中提取globalTransactionId，存入当前线程的 ThreadLocal，确保后续本地事务能绑定到全局事务。

三、Seata 四大事务模式：原理、场景与对比

Seata 支持四种事务模式，每种模式的实现原理、适用场景差异显著，需根据业务特性选择。

3.1、 AT 模式：自动补偿的 "无侵入" 方案（推荐首选）

AT 模式是 Seata 最常用的模式，基于 "本地事务 + undo 日志 + 全局锁" 实现自动提交 / 回滚，无需手动编写回滚逻辑，适合 "读多写少、无复杂业务逻辑" 的场景（如电商下单、库存扣减）。

3.1.1、核心原理（3 步本地事务执行）

1、预执行（Prepare）

RM 执行本地 SQL（如UPDATE stock SET num = num -1 WHERE id = 1）；

自动生成 "undo 日志"（记录修改前的数据快照，如num=10）和 "redo 日志"（记录修改后的数据，如num=9），存入本地数据库的undo_log表；

向 TC 申请 "全局锁"（防止其他事务修改同一数据，避免脏写）。

2、全局决议（Commit/Rollback）

若所有分支事务预执行成功，TC 下达 "全局提交" 指令；

若任一分支事务失败，TC 下达 "全局回滚" 指令。

3、最终执行（Commit/Rollback）

提交：RM 删除undo_log表中的对应记录（无需额外操作，本地事务已预执行成功），释放全局锁；

回滚：RM 基于undo_log中的快照数据，执行回滚 SQL（如UPDATE stock SET num = 10 WHERE id = 1），删除undo_log记录，释放全局锁。

3.1.2、适用场景与优缺点

适用场景：支持 MySQL、Oracle 等关系型数据库，无特殊业务逻辑的分布式事务（如订单、库存、支付联动）；

优点：无代码侵入（仅需注解）、自动回滚、性能较好；

缺点：不支持非关系型数据库（如 MongoDB），不支持自定义回滚逻辑。

3.2、 TCC 模式：自定义补偿的 "高灵活" 方案

TCC（Try-Confirm-Cancel）模式基于 "业务侵入式" 设计，需手动实现 "Try（资源检查与预留）、Confirm（确认执行）、Cancel（补偿回滚）" 三个接口，适合 "业务逻辑复杂、需自定义资源预留" 的场景（如资金转账、预约业务）。

3.2.1、核心原理（3 阶段执行）

Try 阶段：检查并预留资源（如转账场景：检查转出账户余额是否充足，冻结转账金额）；

Confirm 阶段：确认执行（如转账场景：扣减转出账户冻结金额，增加转入账户余额），该阶段必须保证 "幂等性"（重复执行不影响结果）；

Cancel 阶段：补偿回滚（如转账场景：解冻转出账户冻结金额），同样需保证幂等性。

3.2.2、适用场景与优缺点

适用场景：非关系型数据库（如 Redis、MongoDB）、需自定义资源预留的业务（如酒店预约、资金冻结）；

优点：灵活性高（支持自定义逻辑）、不依赖数据库事务、性能好；

缺点：代码侵入性强（需手动实现 3 个接口）、需处理幂等性与空回滚问题。

3.3、 SAGA 模式：长事务的 "异步补偿" 方案

SAGA 模式基于 "状态机 + 异步补偿" 设计，将分布式事务拆分为多个 "本地事务步骤"，每个步骤执行成功后异步触发下一步，失败则异步执行补偿操作，适合 "长事务、异步执行" 的场景（如订单履约、物流调度）。

3.3.1、核心原理（两种执行模式）

正向顺序执行 + 反向补偿：若步骤 1→步骤 2→步骤 3 执行，步骤 3 失败则执行步骤 2 的补偿→步骤 1 的补偿；

状态机驱动：通过配置状态机（如 JSON 定义步骤流转规则），支持更复杂的分支逻辑（如步骤 2 成功后，根据条件选择执行步骤 3 或步骤 4）。

3.3.2、适用场景与优缺点

适用场景：长事务（如跨天的订单履约）、异步业务（如消息通知、物流更新）、非实时一致性需求；

优点：支持长事务、低资源占用（异步执行）、可扩展复杂流程；

缺点：一致性级别低（最终一致性）、不支持实时业务。

3.4、 TXC 模式：分布式事务的 "强一致性" 方案

TXC（Transaction eXtended Context）模式是 Seata 针对阿里云 DRDS（分布式关系型数据库）的专属模式，基于 "分布式锁 + SQL 重写" 实现强一致性，适合 "使用 DRDS 的阿里云微服务场景"。

3.4.1、核心原理

SQL 重写：RM 拦截 SQL，自动添加 "分布式锁条件"（如WHERE ... AND drds_transaction_id = ?）；

分布式锁：TC 统一管理分布式锁，确保同一数据在同一全局事务中仅被修改一次；

强一致性：所有分支事务提交前，数据处于 "锁定状态"，提交后释放锁，保证全局数据一致。

3.4.2、适用场景与优缺点

适用场景：阿里云 DRDS 用户、强一致性需求的分布式事务；

优点：强一致性、无 undo 日志、性能较好；

缺点：依赖阿里云 DRDS，兼容性差。

3.5、四种模式对比与选择建议

|------|-------|------------|----|-----------------|-------|
| 事务模式 | 一致性级别 | 代码侵入性 | 性能 | 适用场景 | 推荐度 |
| AT | 最终一致性 | 低（无侵入） | 高 | 关系型数据库、无复杂业务逻辑 | ★★★★★ |
| TCC | 最终一致性 | 高（需写 3 接口） | 高 | 非关系型数据库、自定义资源预留 | ★★★★☆ |
| SAGA | 最终一致性 | 中（需配置步骤） | 中 | 长事务、异步业务 | ★★★☆☆ |
| TXC | 强一致性 | 低（无侵入） | 中 | 阿里云 DRDS、强一致性需求 | ★★☆☆☆ |

四、Seata 实战：Spring Cloud 集成 AT 模式（附代码）

以 "订单服务调用库存服务" 为例，演示 Seata AT 模式的完整集成流程，环境基于 Spring Cloud Alibaba + Nacos + MySQL。

4.1、环境准备（3 步）

4.1.1、部署 Seata Server（TC）

1、下载 Seata Server ：从Seata 官网下载最新版本（如 1.7.0）；

2、配置注册中心与配置中心：修改conf/registry.conf，指定 Nacos 作为注册中心与配置中心：

XML 复制代码

registry {
  type = "nacos"
  nacos {
    application = "seata-server"
    serverAddr = "127.0.0.1:8848"
    group = "SEATA_GROUP"
    namespace = ""
  }
}
config {
  type = "nacos"
  nacos {
    serverAddr = "127.0.0.1:8848"
    group = "SEATA_GROUP"
    namespace = ""
  }
}

3、启动 Seata Server ：执行bin/seata-server.bat（Windows）或bin/seata-server.sh（Linux），默认端口 8091。

4.1.2、创建数据库表

全局事务表（TC 端）：Seata Server 默认使用seata数据库，需手动创建global_table（全局事务表）、branch_table（分支事务表）等，SQL 脚本见Seata 官网；
undo_log 表（RM 端）：每个微服务的数据库需创建undo_log表（AT 模式用于存储回滚快照）：

sql 复制代码

CREATE TABLE `undo_log` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `branch_id` bigint NOT NULL,
  `xid` varchar(100) NOT NULL,
  `context` varchar(128) NOT NULL,
  `rollback_info` longblob NOT NULL,
  `log_status` int NOT NULL,
  `log_created` datetime NOT NULL,
  `log_modified` datetime NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

4.1.3、微服务数据库准备

订单库（order_db）：创建order表，存储订单信息；

库存库（stock_db）：创建stock表，存储商品库存信息。

4.2、微服务集成 Seata（以订单服务、库存服务为例）

4.2.1、引入依赖（pom.xml）

XML 复制代码

<!-- Seata核心依赖 -->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
    <version>2023.0.0.0</version>
</dependency>
<!-- Nacos注册中心依赖（已有可忽略） -->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

4.2.2、配置 Seata（application.yml）

XML 复制代码

spring:
  application:
    name: order-service # 服务名，需与Seata配置中的service.vgroupMapping对应
  cloud:
    alibaba:
      seata:
        tx-service-group: order-service-group # 事务组名，需与Seata Server配置一致
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848 # Nacos地址

# Seata配置（也可在Nacos配置中心配置）
seata:
  registry:
    type: nacos
    nacos:
      server-addr: 127.0.0.1:8848
      group: SEATA_GROUP
  config:
    type: nacos
    nacos:
      server-addr: 127.0.0.1:8848
      group: SEATA_GROUP
  service:
    vgroup-mapping:
      order-service-group: default # 事务组与Seata Server集群的映射（default为默认集群名）
    grouplist:
      default: 127.0.0.1:8091 # Seata Server地址

4.2.3、编写业务代码（AT 模式核心）

1、订单服务（TM+RM）：发起全局事务，调用库存服务；

java 复制代码

import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestParam;

// 远程调用库存服务
@FeignClient(name = "stock-service")
public interface StockFeignClient {
    @PostMapping("/stock/deduct")
    Boolean deductStock(@RequestParam("productId") Long productId, @RequestParam("num") Integer num);
}

// 订单服务业务层（TM：全局事务发起者）
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
import com.alibaba.fastjson.JSONObject;
import com.alibaba.nacos.common.utils.UuidUtils;
import io.seata.spring.annotation.GlobalTransactional;
import javax.annotation.Resource;

@Service
public class OrderService {
    @Resource
    private OrderMapper orderMapper; // 订单DAO
    @Resource
    private StockFeignClient stockFeignClient; // 库存服务Feign客户端

    // 全局事务注解：标记该方法为全局事务入口
    @GlobalTransactional(rollbackFor = Exception.class)
    @Transactional
    public Boolean createOrder(Long productId, Integer num, Long userId) {
        // 1. 本地事务：创建订单
        Order order = new Order();
        order.setOrderId(UuidUtils.generateUuid());
        order.setProductId(productId);
        order.setNum(num);
        order.setUserId(userId);
        order.setStatus(0); // 0：未支付
        orderMapper.insert(order);
        System.out.println("订单创建成功：" + JSONObject.toJSONString(order));

        // 2. 远程调用：扣减库存（触发库存服务的分支事务）
        Boolean deductResult = stockFeignClient.deductStock(productId, num);
        if (!deductResult) {
            // 若库存扣减失败，抛出异常，触发全局回滚
            throw new RuntimeException("库存不足，订单创建失败");
        }

        return true;
    }
}

2、库存服务（RM）：执行本地事务（扣减库存）；

java 复制代码

// 库存服务业务层（RM：分支事务参与者）
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
import javax.annotation.Resource;

@Service
public class StockService {
    @Resource
    private StockMapper stockMapper; // 库存DAO

    // 本地事务：扣减库存（无需@GlobalTransactional，自动注册为分支事务）
    @Transactional
    public Boolean deductStock(Long productId, Integer num) {
        // 1. 检查库存
        Stock stock = stockMapper.selectByProductId(productId);
        if (stock == null || stock.getNum() < num) {
            System.out.println("库存不足：productId=" + productId + ", 剩余库存=" + (stock == null ? 0 : stock.getNum()));
            return false;
        }

        // 2. 扣减库存
        int rows = stockMapper.deductStock(productId, num);
        if (rows > 0) {
            System.out.println("库存扣减成功：productId=" + productId + ", 扣减数量=" + num);
            return true;
        } else {
            System.out.println("库存扣减失败：productId=" + productId);
            return false;
        }
    }
}

4.2.4、测试全局事务

正常场景：库存充足时，订单创建成功，库存扣减成功，全局事务提交；

异常场景：库存不足时，库存服务返回 false，订单服务抛出异常，全局事务回滚（订单记录被删除，库存无变化）。

五、Seata 进阶：生产环境关键特性与优化

5.1、事务组与集群高可用

Seata Server 支持集群部署，通过 "事务组（tx-service-group）" 实现负载均衡与故障转移：

配置事务组映射：在 Nacos 配置中心添加service.vgroupMapping.order-service-group=default，表示 "order-service-group" 事务组对应 "default" 集群；

部署 Seata Server 集群：多个 Seata Server 节点配置相同的registry.conf，自动加入同一集群；

高可用原理：RM/TM 通过 Nacos 获取 Seata Server 集群列表，基于负载均衡选择节点通信，单个节点故障不影响全局事务。

5.2、数据持久化：避免 TC 数据丢失

Seata Server 默认使用内存存储全局事务状态，重启后数据丢失，生产环境需配置持久化：

DB 模式（推荐）：将全局事务状态存储到 MySQL/Oracle，修改conf/application.yml：

XML 复制代码

store:
  mode: db # 持久化模式：db/redis/file
  db:
    datasource: druid
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://127.0.0.1:3306/seata?useUnicode=true&characterEncoding=utf8
    user: root
    password: 123456

Redis 模式：适合高并发场景，需配置 Redis 集群地址与密码。

5.3、事务隔离级别

Seata 支持两种全局事务隔离级别（基于 AT 模式）：

读未提交（Read Uncommitted）：默认级别，事务未提交时，其他事务可读取其修改的数据；

读已提交（Read Committed）：需在@GlobalTransactional中指定isolation = GlobalTransactionIsolation.READ_COMMITTED，仅读取已提交的事务数据，避免脏读。

5.4、性能优化：提升高并发场景吞吐量

异步提交：全局事务提交时，TC 异步通知 RM 提交分支事务，减少同步等待时间，配置seata.enableAsyncCommit=true；

批量分支注册：一次请求注册多个分支事务，减少 TC 与 RM 的通信次数，配置seata.branchRegisterBatchMode=true；

undo 日志清理：定期清理过期的undo_log记录（如保留 7 天），避免表数据过大，可通过定时任务执行DELETE FROM undo_log WHERE log_created < DATE_SUB(NOW(), INTERVAL 7 DAY)。

六、Seata 常见问题与解决方案

6.1、问题 1：全局事务未触发回滚

原因：

未添加@GlobalTransactional注解，或注解未生效（如方法不是 public、未被 Spring 管理）；

异常被捕获（如try-catch未抛出异常），TM 未向 TC 发送回滚请求；

undo_log表未创建或配置错误，RM 无法生成回滚快照。

解决方案：

检查@GlobalTransactional注解的方法权限与 Spring Bean 注册；

确保异常向上抛出（或在catch中调用TransactionContextHolder.getCurrent().setRollbackOnly()）；

验证undo_log表结构与数据库连接配置。

6.2、问题 2：全局锁等待导致事务超时

现象：事务执行时提示 "global lock wait timeout"，分支事务无法获取全局锁；

原因：同一数据被多个全局事务修改，前一事务未释放全局锁；

解决方案：

优化业务逻辑，减少同一数据的并发修改（如分库分表）；

调整全局锁超时时间，配置seata.lock.timeout=30000（单位：毫秒）；

避免长事务，及时提交 / 回滚全局事务。

6.3、问题 3：事务上下文传播失败

现象：远程调用时globalTransactionId未传递，分支事务未绑定到全局事务；

原因：

未引入 Seata 的 Feign/Dubbo 拦截器（如 Spring Cloud 集成时需确保spring-cloud-starter-alibaba-seata依赖正确）；

自定义拦截器覆盖了 Seata 的事务上下文传播逻辑；

解决方案：

检查依赖是否完整，确保 Seata 的FeignRequestInterceptor被自动配置；

自定义拦截器时，先执行 Seata 的上下文传播逻辑（如SeataHandlerInterceptor）。

七、结语：Seata 在微服务生态中的价值与展望

Seata 通过 "统一事务模型 + 多模式支持"，降低了微服务分布式事务的实现门槛，解决了传统方案 "侵入性强、性能差、维护难" 的痛点。在实际使用中，需根据业务场景选择合适的事务模式（如 AT 模式用于常规业务，TCC 模式用于复杂业务），并通过集群部署、数据持久化、性能优化保障生产环境稳定。

未来，Seata 将进一步向 "云原生" 方向演进，支持 K8s 部署、Service Mesh 集成、多云环境适配，同时提升事务性能与一致性级别，成为微服务分布式事务管理的 "标准工具"。掌握 Seata，不仅能解决实际业务中的数据一致性问题，更能深入理解分布式系统的核心设计思想 ------"如何在分布式环境中平衡一致性、可用性与性能"。

Seata 深度解析：微服务分布式事务管理的实践指南

一、微服务事务痛点：为什么需要 Seata？

1.1、 分布式事务的本质：跨服务的数据一致性

1.2、 传统解决方案的局限

1.3、 Seata 的核心价值：简化分布式事务

二、Seata 核心架构：3 大角色与事务流程

2.1、 三大核心角色定义

2.2、 全局事务执行流程（4 步拆解）

2.3、 事务上下文传播

三、Seata 四大事务模式：原理、场景与对比

3.1、 AT 模式：自动补偿的 "无侵入" 方案（推荐首选）

3.1.1、 核心原理（3 步本地事务执行）

3.1.2、 适用场景与优缺点

3.2、 TCC 模式：自定义补偿的 "高灵活" 方案

3.2.1、 核心原理（3 阶段执行）

3.2.2、 适用场景与优缺点

3.3、 SAGA 模式：长事务的 "异步补偿" 方案

3.3.1、 核心原理（两种执行模式）

3.3.2、 适用场景与优缺点

3.4、 TXC 模式：分布式事务的 "强一致性" 方案

3.4.1、 核心原理

3.4.2、 适用场景与优缺点

3.5、 四种模式对比与选择建议

四、Seata 实战：Spring Cloud 集成 AT 模式（附代码）

4.1、 环境准备（3 步）

4.1.1、 部署 Seata Server（TC）

4.1.2、 创建数据库表

4.1.3、 微服务数据库准备

4.2、 微服务集成 Seata（以订单服务、库存服务为例）

4.2.1、 引入依赖（pom.xml）

4.2.2、 配置 Seata（application.yml）

4.2.3、 编写业务代码（AT 模式核心）

4.2.4、 测试全局事务

五、Seata 进阶：生产环境关键特性与优化

5.1、 事务组与集群高可用

5.2、 数据持久化：避免 TC 数据丢失

5.3、 事务隔离级别

5.4、 性能优化：提升高并发场景吞吐量

六、Seata 常见问题与解决方案

6.1、 问题 1：全局事务未触发回滚

6.2、 问题 2：全局锁等待导致事务超时

6.3、 问题 3：事务上下文传播失败

七、结语：Seata 在微服务生态中的价值与展望

1.1、分布式事务的本质：跨服务的数据一致性

1.2、传统解决方案的局限

2.1、三大核心角色定义

2.2、全局事务执行流程（4 步拆解）

2.3、事务上下文传播

3.1.1、核心原理（3 步本地事务执行）

3.1.2、适用场景与优缺点

3.2.1、核心原理（3 阶段执行）

3.2.2、适用场景与优缺点

3.3.1、核心原理（两种执行模式）

3.3.2、适用场景与优缺点

3.4.1、核心原理

3.4.2、适用场景与优缺点

3.5、四种模式对比与选择建议

4.1、环境准备（3 步）

4.1.1、部署 Seata Server（TC）

4.1.2、创建数据库表

4.1.3、微服务数据库准备

4.2、微服务集成 Seata（以订单服务、库存服务为例）

4.2.1、引入依赖（pom.xml）

4.2.2、配置 Seata（application.yml）

4.2.3、编写业务代码（AT 模式核心）

4.2.4、测试全局事务

5.1、事务组与集群高可用

5.2、数据持久化：避免 TC 数据丢失

5.3、事务隔离级别

5.4、性能优化：提升高并发场景吞吐量

6.1、问题 1：全局事务未触发回滚

6.2、问题 2：全局锁等待导致事务超时

6.3、问题 3：事务上下文传播失败