Seata AT 模式实战接入要点

AT 模式是最常用的 Seata 模式：你在业务方法上声明全局事务，框架通过 undo_log 自动完成提交与回滚，业务代码几乎无侵入。本章按"部署 Server → 接入客户端 → 建表 → 声明事务 → 验证回滚"的顺序给出要点，配置细节以官方文档为准。

前置：部署 seata-server（TC）

从官方发布页下载 seata-server 发行包（写作时 2.3.x）并解压。Server 端配置集中在 conf 目录：把注册方式配为 Nacos，使 TC 以服务名（默认 seata-server）与集群名（默认 default）注册到 Nacos，客户端才能找到它；事务配置（store 等）可存本地文件或也放进 Nacos。启动脚本位于 bin 目录（seata-server 启动命令、端口 8091 默认），先启动 Nacos 再启动 seata-server，看到"Server started"类日志即就绪。2.x 的配置文件名与字段随版本有调整，一律以官方文档为准。

客户端接入：依赖与配置

事务链路上的每个参与服务（order-service、inventory-service 等）都引入客户端依赖：

<dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-spring-boot-starter</artifactId>
</dependency>

seata:
  application-id: order-service
  tx-service-group: sc-tx-group            # 事务分组名，各服务保持一致
  registry:
    type: nacos
    nacos:
      server-addr: localhost:8848
      cluster: default                     # 与 Server 注册的集群名一致
  service:
    vgroup-mapping:
      sc-tx-group: default                 # 事务分组 → 集群 映射

其中事务分组（tx-service-group）是客户端与 Server 之间的逻辑纽带：同一次全局事务的所有参与方必须使用同一分组。注册中心、集群名、映射字段的准确写法随版本演进，请以官方示例配置核对。

数据源代理与 undo_log 表

AT 的回滚依赖两件事：一是数据源被 Seata 代理（starter 默认开启自动代理，可在配置中开关），代理拦截 SQL 生成前后镜像并记录 undo_log；二是每个参与事务的数据库都要建 undo_log 表，官方文档与示例仓库提供了 MySQL 等各数据库的建表脚本，按你的方言选用。表建错或漏建，回滚会失败，接入自检的第一步就是确认各库 undo_log 存在且可写。

声明全局事务

事务入口（最外层方法，通常是发起方 order-service 的创建订单方法）加 @GlobalTransactional，链路中其他服务的本地方法保持普通 @Transactional：

@GlobalTransactional(name = "create-order-tx", rollbackFor = Exception.class)
public OrderDto createOrder(OrderCreateCmd cmd) {
    orderMapper.insert(order);              // 本地事务：写订单库
    inventoryClient.deduct(cmd);            // Feign 调库存服务（其本地 @Transactional）
    accountClient.decrease(cmd);            // Feign 调账户服务
    return orderDto;
}

参与方照常只关心自己的本地事务；全局提交/回滚由 TM 向 TC 请求，RM 执行。rollbackFor 要显式声明，避免"只回滚 RuntimeException、不回滚受检异常"的默认行为误事。

验证回滚：让一个分支失败

在账户服务扣减方法里故意抛异常（模拟余额不足），再调用创建订单接口，观察三个结果：接口返回失败；订单表与库存表里本次插入/扣减的数据被自动回滚；日志中出现全局事务回滚相关记录（可看到各分支 undo 执行）。这就是 AT 的完整闭环：任一支分失败 → TC 通知全部回滚 → 数据回到事务前状态。

实战要点清单

一是 @GlobalTransactional 必须放在最外层入口：放在中间服务上会导致事务边界混乱，子调用抛出异常时外层已提交的部分无法回滚。二是 AT 只适合关系型数据库常规 SQL：DDL、非事务表、不走代理数据源的操作无法回滚。三是全局锁会放大热点行的等待：高并发下同一条记录被多个全局事务争抢时，第二个事务会等待全局锁，吞吐下降明显，需要结合业务评估或改 TCC。四是超时与重试：长事务建议设置合理的全局事务超时，客户端与服务端版本必须一致。五是回滚日志会膨胀：生产要配套 undo_log 的清理机制（官方提供清理方案）。

小结

AT 模式接入 = 部署 TC（注册进 Nacos）+ 各服务引入客户端并配同一事务分组 + 各库建 undo_log + 入口方法加 @GlobalTransactional。它把分布式事务的复杂度收敛到"配置 + 一张表"，是 Seata 的默认首选；吞吐敏感的热点场景再考虑 TCC。分布式事务保证数据一致，消息与异步场景的一致性问题，我们转到 Spring Cloud Stream 篇章继续。