当我们把一个单体内核拆成多个微服务之后最先崩溃的往往不是接口性能而是数据一致性。最典型的例子就是下单扣库存订单服务把订单写入自己的库库存服务再扣减另一个库的数量。如果第二笔操作失败前一笔操作已经写进去了数据库本地事务帮不了你因为这是两个独立的数据库连接两个不同的事务。于是账面上多了一笔没有库存的订单或者库存被多扣了却没有订单。很多团队在这个阶段才开始认真研究分布式事务随手翻开资料就会发现结论几乎都会指向同一个名字Seata。它是目前国内 Spring Cloud 微服务架构中使用最广泛的分布式事务框架之一社区活跃、资料多、接入成本相对可控。更关键的是它把“分布式事务”从理论名词变成了可以实际落地的工程方案。这篇文章会先讲清楚 Seata 到底解决什么问题然后拆解它的核心架构和几种事务模式最后用一个 Spring Cloud 下单扣库存的完整示例带你跑通 Seata 的 AT 模式并说明验证方式、常见故障排查方法和工程建议。读完你应该能判断自己的项目是否需要 Seata以及它最合理的接入方式是什么。1. 这篇文章真正要解决的问题先直接给一个判断Seata 不是分布式事务的万能药但它是把“跨服务强一致”做成可接受工程成本的最实际路径之一。为什么这么说因为分布式事务有太多理论模型比如两阶段提交、三阶段提交、补偿事务、本地消息表、事务消息但真正能在 Spring Cloud 体系里直接落地、被大量生产项目验证过的方案并不多。Seata 之所以流行核心原因是它的 AT 模式对业务代码侵入非常小开发者几乎只需要在业务入口加一个注解再配合几个配置项就能让原本跨库、跨服务的事务获得提交或回滚能力。这篇文章会围绕三个问题展开微服务拆分后本地事务为什么无法解决跨库数据一致性问题。Seata 的架构角色和事务模式分别适合什么场景。从环境搭建、代码实现到运行验证Seata 的 AT 模式到底怎么落地。如果你正在做微服务改造或者你的系统已经出现“订单和库存对不上”“账户余额和流水对不上”这类问题这篇文章会比较适合你。如果你是技术负责人需要给团队一个分布式事务方案这篇文章也可以帮你快速建立判断框架。2. 基础概念与核心原理2.1 分布式事务问题是怎么产生的在没有微服务的时候一个下单流程通常是单库多表操作比如订单表、库存表、账户表都在同一个数据库里。数据库的本地事务用 BEGIN、COMMIT、ROLLBACK 就能保证要么全部成功、要么全部失败。微服务拆分后订单数据、库存数据、账户数据各自独立的数据库甚至分属不同的物理机器。这个时候你面对的不再是同一个事务管理器能管理的范围而是多个独立事务之间的协调问题。一个业务流程横跨多个服务任意一个环节失败都需要让前面已经成功的操作撤销。这就是分布式事务要解决的问题本质是跨多个数据源、多个服务的事务一致性。2.2 Seata 是什么Seata 是 Simple Extensible Autonomous Transaction Architecture 的缩写一个开源的分布式事务中间件。它由阿里巴巴发起目前是 Apache 基金会孵化项目。它在设计上把一次分布式事务拆分为全局事务和分支事务全局事务由发起方开启覆盖整个业务流程包含多个参与服务。分支事务全局事务中每一个参与服务内部执行的本地事务。Seata 的任务就是协调这些分支事务让它们在外界看来像一个整体事务一样要么全部生效要么全部回滚。2.3 Seata 的四种事务模式Seata 提供四种事务模式分别是 AT、TCC、SAGA 和 XA。它们解决同一个问题但侵入性、性能、一致性强度各不相同。AT 模式是 Seata 最有特色的模式。它对业务代码侵入最小核心思路是“自动补偿”。AT 模式会代理数据源在业务 SQL 执行前记录数据快照到undo_log表业务 SQL 执行成功后进入两阶段提交流程。如果全局事务需要回滚Seata 根据undo_log中的快照自动生成反向 SQL把数据恢复到操作前状态。TCC 模式要求业务方自己实现 Try、Confirm、Cancel 三组接口侵入性最强但调优空间也最大适合资源锁定和补偿逻辑需要精细控制的场景。SAGA 模式适合长事务将一个大事务拆分为多个本地事务每个事务都有对应的补偿操作由状态机引擎编排执行。XA 模式借助数据库原生支持的两阶段提交协议来实现强一致对业务代码几乎无侵入但资源锁时间较长性能开销相对高。四种模式的对比可以看下面的表模式对业务侵入一致性性能适用场景AT低最终一致较好多数基于关系型数据库的业务场景TCC高最终一致较好需要人工控制资源锁和补偿逻辑的场景SAGA中最终一致较好长事务、基于状态机的流程编排场景XA低强一致一般数据库原生支持且可接受锁时长的场景对于大多数 Spring Cloud 内部服务AT 模式是最优先考虑的选择。TCC 更适用于对外部资源或非关系型存储的精确补偿SAGA 更适合有明确流程节点划分的长业务链。2.4 一个容易误解的地方很多人以为 Seata 是消息中间件或者定时任务其实它是一个事务协调平台。它不负责传输业务数据也不帮你重放消息它的核心工作是维护全局事务状态、记录分支事务状态、在合适时机下发提交或回滚指令。还有一点容易误解AT 模式的回滚依赖于数据库undo_log表而不是应用层做逆向业务操作。它是在数据层面做恢复不调用业务接口。这意味着业务代码里写的逻辑补偿并不需要额外处理但前提是undo_log表在每个业务库中都要创建。3. Seata 核心架构TC、TM、RM 分别负责什么要理解 Seata必须先理解它的三个核心角色。TC 是事务协调者独立部署的 Seata Server负责维护全局事务和分支事务的状态驱动全局提交或回滚。可以把它理解为总调度室所有分布式事务的元信息都在 TC 侧。TM 是事务管理器负责定义全局事务的范围。通常体现在业务方法上的GlobalTransactional注解。TM 向 TC 发起开启全局事务、提交或回滚的请求。它是全局事务的发起入口。RM 是资源管理器负责管理分支事务的资源。在 AT 模式下RM 通过代理数据源拦截 JDBC 操作向 TC 注册分支事务并记录回滚日志。它负责真正执行本地 SQL并上报事务结果。一次完整的 AT 模式分布式事务流程大致如下TM 向 TC 开启全局事务拿到全局事务 ID也就是 XID。XID 通过服务调用链路传播到下游服务。下游服务在执行本地 SQL 前RM 把业务数据的前镜像写入undo_log。本地 SQL 执行完成RM 把后镜像写入undo_log并向 TC 注册分支事务。业务方法执行成功TM 发起全局提交如果任意服务抛出异常TM 发起全局回滚。全局提交时TC 通知各 RM 删除undo_log记录。全局回滚时TC 通知各 RM 根据undo_log构造反向 SQL 恢复数据。这里面最关键的机制就是“前镜像和后镜像”。前镜像是该行数据在执行 SQL 之前的值后镜像是执行之后的值。回滚时如果当前数据等于后镜像说明数据没有被其他事务改过可以直接恢复成前镜像如果已经被改过就需要做冲突处理。这也是为什么 Seata 还要依赖全局锁来控制写写冲突。在 Spring Cloud 集成场景中还需要理解“事务分组”这个概念。客户端配置tx-service-group指定事务分组例如my_test_tx_group然后通过配置映射到 Seata Server 集群名客户端再根据集群名从注册中心找到 TC。这个分组配置经常是大家启动失败的第一原因下面实战部分会重点看它。4. 环境准备与前置条件4.1 需要准备哪些组件本文的实战示例以一个常见的 Seata Nacos Spring Cloud 组合为例涉及以下环境JDK 8 及以上。Maven 3.6 及以上。MySQL 5.7 或 8.x需要准备两个数据库分别给订单服务和库存服务使用。Nacos 作为注册中心和配置中心。Seata Server独立部署事务协调器 TC。两个 Spring Boot 服务分别模拟订单服务和库存服务。需要提醒的是Seata 与 Spring Cloud Alibaba、Nacos 的版本之间存在依赖关系具体版本请以你项目实际使用的 Spring Cloud Alibaba BOM 为准。本文代码示例重点演示通用思路不绑定某个精确版本号。4.2 安装并启动 NacosNacos 的启动相对简单。下载 Nacos 后进入bin目录在 Linux 或 macOS 上执行sh startup.sh -m standaloneWindows 环境使用startup.cmd -m standalone。启动成功后浏览器访问http://127.0.0.1:8848/nacos默认用户名密码都是nacos。Nacos 在这里的作用是作为注册中心。Seata Server 会把自己注册到 Nacos两个业务服务也会注册到 Nacos并通过 Nacos 发现彼此。4.3 下载并配置 Seata ServerSeata Server 在 Seata 官方仓库或 GitHub Releases 页面下载。解压后需要关注两个目录conf目录和bin目录。conf里有application.yml、registry.conf等配置文件不同版本文件名略有差异。在本文示例中我们可以通过配置文件让 Seata Server 使用 Nacos 作为注册中心。以常见的 Seata 1.x 版本的registry.conf为例核心内容如下registry { type nacos nacos { serverAddr 127.0.0.1:8848 namespace cluster default } } config { type nacos nacos { serverAddr 127.0.0.1:8848 namespace } }如果你的 Seata 版本不是通过registry.conf配置而是在application.yml中配置含义是相同的指定 registry 类型和 config 类型为 Nacos。请以具体版本和官方文档为准。配置完成后进入bin目录启动 Seata Serversh seata-server.sh -p 8091 -h 127.0.0.1启动成功后在 Nacos 的服务列表里应该能看到名为serverAddr对应的 Seata Server 服务实例。这个动作说明 TC 已经就绪。4.4 初始化业务数据库与 undo_log 表我们需要为两个服务分别创建数据库例如seata_order和seata_storage。先执行订单库的建表语句CREATE DATABASE IF NOT EXISTS seata_order DEFAULT CHARSET utf8mb4; USE seata_order; CREATE TABLE t_order ( id bigint(20) NOT NULL AUTO_INCREMENT, order_id varchar(64) NOT NULL, product_id varchar(32) NOT NULL, count int(11) NOT NULL, user_id varchar(32) NOT NULL, status int(11) NOT NULL DEFAULT 1, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;再执行库存库的建表语句CREATE DATABASE IF NOT EXISTS seata_storage DEFAULT CHARSET utf8mb4; USE seata_storage; CREATE TABLE storage ( id bigint(20) NOT NULL AUTO_INCREMENT, product_id varchar(32) NOT NULL, remaining int(11) NOT NULL DEFAULT 0, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; INSERT INTO storage (product_id, remaining) VALUES (P001, 100);每个业务库中还必须创建 Seata AT 模式依赖的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) NOT NULL, rollback_info longblob 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_log (xid, branch_id) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4;注意undo_log表必须和业务表在同一个数据库。如果订单库有业务表而没有undo_log表回滚时会报分支回滚失败。5. 核心流程拆解与完整示例代码5.1 项目结构规划本文示例包含两个服务order-service端口 8081负责创建订单是整个全局事务的发起方。storage-service端口 8082负责扣减库存是全局事务的参与方。调用关系是order-service先插入订单然后通过 OpenFeign 调用storage-service扣减库存。如果库存不足storage-service抛出异常order-service捕获到异常后整个全局事务自动回滚订单插入被撤销。这种设计可以很直观地验证分布式事务的回滚效果成功时两边数据都变化失败时两边数据都还原。5.2 引入依赖两个服务都需要引入 Spring Boot Web、Spring Cloud OpenFeign、Nacos Discovery、Spring JDBC 以及 Seata 相关依赖。以 Maven 为例核心依赖如下dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-seata/artifactId /dependency dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-openfeign/artifactId /dependency dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-jdbc/artifactId /dependency依赖版本由 Spring Cloud Alibaba BOM 统一管理不需要在项目里手工指定 Seata 版本。如果你的工程比较老旧需要手动管理版本建议优先参考官方提供的版本兼容矩阵。5.3 配置 application.ymlorder-service的src/main/resources/application.yml配置如下server: port: 8081 spring: application: name: order-service cloud: nacos: discovery: server-addr: 127.0.0.1:8848 datasource: url: jdbc:mysql://127.0.0.1:3306/seata_order?useUnicodetruecharacterEncodingutf8useSSLfalse username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver seata: enabled: true application-id: order-service tx-service-group: my_test_tx_group registry: type: nacos nacos: server-addr: 127.0.0.1:8848storage-service的配置与order-service类似端口改成 8082数据库 URL 改成seata_storage应用名改成storage-service。事务分组my_test_tx_group是我们在业务代码中定义的逻辑分组。客户端会拿着这个分组去找对应的 Seata Server 集群不同服务之间要保持一致否则会出现找不到 Seata Server 的报错。5.4 订单服务核心代码OrderService是全局事务的发起方关键在于GlobalTransactional注解// 文件路径order-service/src/main/java/com/example/order/service/OrderService.java Service public class OrderService { private final JdbcTemplate jdbcTemplate; private final StorageFeignClient storageFeignClient; public OrderService(JdbcTemplate jdbcTemplate, StorageFeignClient storageFeignClient) { this.jdbcTemplate jdbcTemplate; this.storageFeignClient storageFeignClient; } GlobalTransactional(name create-order-global-tx, timeoutMills 30000) public void createOrder(String orderId, String productId, Integer count, String userId) { jdbcTemplate.update( INSERT INTO t_order (order_id, product_id, count, user_id, status) VALUES (?, ?, ?, ?, 1), orderId, productId, count, userId ); storageFeignClient.deductStock(productId, count); } }代码逻辑非常简单先写订单库再远程调库存服务扣库存。真正容易踩坑的是远程调用不能吞异常。如果storage-service扣减失败后返回了一个包含错误码的对象但 Feign Client 没有把非 2xx 状态抛出order-service会认为调用成功全局事务自然也就不会回滚。所以这里的 Feign 接口要确保业务异常能通过 HTTP 状态码或抛异常的方式传递回来。对应的 Controller// 文件路径order-service/src/main/java/com/example/order/controller/OrderController.java RestController RequestMapping(/order) public class OrderController { private final OrderService orderService; public OrderController(OrderService orderService) { this.orderService orderService; } PostMapping(/create) public String create( RequestParam(orderId) String orderId, RequestParam(productId) String productId, RequestParam(count) Integer count, RequestParam(userId) String userId) { orderService.createOrder(orderId, productId, count, userId); return success; } }5.5 库存服务核心代码库存服务的StorageService使用 JdbcTemplate 执行扣减 SQL。这里用了一个防超扣的条件只有剩余库存大于等于扣减数量时才更新否则影响行数为 0直接抛出异常// 文件路径storage-service/src/main/java/com/example/storage/service/StorageService.java Service public class StorageService { private final JdbcTemplate jdbcTemplate; public StorageService(JdbcTemplate jdbcTemplate) { this.jdbcTemplate jdbcTemplate; } public void deductStock(String productId, Integer count) { int rows jdbcTemplate.update( UPDATE storage SET remaining remaining - ? WHERE product_id ? AND remaining ?, count, productId, count ); if (rows 0) { throw new RuntimeException(库存不足); } } }对应的 Controller 和 Feign 接口// 文件路径storage-service/src/main/java/com/example/storage/controller/StorageController.java RestController RequestMapping(/storage) public class StorageController { private final StorageService storageService; public StorageController(StorageService storageService) { this.storageService storageService; } PostMapping(/deduct) public String deduct(RequestParam(productId) String productId, RequestParam(count) Integer count) { storageService.deductStock(productId, count); return success; } }在order-service中定义 Feign Client// 文件路径order-service/src/main/java/com/example/order/client/StorageFeignClient.java FeignClient(name storage-service, path /storage) public interface StorageFeignClient { PostMapping(/deduct) String deductStock(RequestParam(productId) String productId, RequestParam(count) Integer count); }5.6 运行顺序与验证命令按顺序启动组件# 1. 启动 Nacos sh startup.sh -m standalone # 2. 启动 Seata Server sh seata-server.sh -p 8091 -h 127.0.0.1 # 3. 启动 storage-service mvn spring-boot:run -pl storage-service # 4. 启动 order-service mvn spring-boot:run -pl order-service所有服务启动成功后执行成功场景请求curl -X POST http://127.0.0.1:8081/order/create?orderIdORD001productIdP001count1userIdU001这时候预期结果有两个seata_order.t_order中新增一条ORD001的订单记录。seata_storage.storage中P001的剩余库存从 100 变成 99。再执行失败场景请求curl -X POST http://127.0.0.1:8081/order/create?orderIdORD002productIdP001count9999userIdU001库存不足会触发RuntimeException全局事务应当回滚。预期结果是接口返回异常信息t_order中没有ORD002这条记录storage的剩余库存保持 99 不变。6. 运行结果与效果验证验证 Seata 是否生效不能只看业务结果还要看事务日志和数据库镜像。6.1 从发起方日志观察order-service的日志中会出现类似下面的关键行global tx started: 192.168.x.x:8091:123456789这说明 TM 已经向 TC 请求并成功开启了全局事务后面的数字就是全局事务 ID也就是 XID。当业务方法成功执行完会出现全局提交相关日志当业务方法抛出异常会出现全局回滚相关日志。如果日志里从头到尾没有出现global tx started说明GlobalTransactional没有生效需要检查 Seata 相关配置是否被正确加载。6.2 从参与方日志观察storage-service的日志中会出现分支事务注册相关日志例如branch transaction registered: 192.168.x.x:8091:123456789:1234567890这表示库存服务执行本地 SQL 后RM 向 TC 注册了分支事务。如果走到这一步说明 XID 已经成功通过服务调用链路传播到了下游。回滚时参与方日志中还会出现 undo 日志删除或反向 SQL 执行的记录。失败场景中库存服务抛出异常后order-service需要先把异常通过网络传递回来然后触发全局回滚两个服务都会收到 TC 的回滚指令。6.3 从数据库观察成功场景下执行订单插入后立即去查询undo_log表。事务提交完成后undo_log中可能只会短暂存在记录最终会被 Seata 清理掉。如果整个流程执行太快你可能看不到记录这是正常的。失败场景下回滚完成后undo_log表中同样会被清理。如果t_order没有新增记录但undo_log里却有残留记录说明回滚阶段出了问题需要重点排查。6.4 判断事务是否真正生效最简单的判断方式就是构造一个必失败的下游操作。库存扣减为 0 行就是一个很合适的失败开关。如果订单没有落库说明全局回滚成功如果订单依然存在说明 Seata 没有起作用或者配置有遗漏。如果只是为了验证 Seata 的提交路径也可以只跑成功场景观察两个库的数据变化。但建议把失败场景一起跑因为验证回滚才是用 Seata 的核心价值。7. 常见问题与排查方法Seata 的安装和接入本身不难但实际运行中确实有不少高频问题。下面把最常见的几种现象整理成表格方便快速定位。问题现象可能原因排查方式解决方案应用启动后报找不到 Seata ServerSeata Server 未启动、注册中心配置不一致、事务分组配置错误检查 Nacos 服务列表确认 Seata Server 实例在线检查各服务事务分组是否一致启动 Seata Server统一事务分组和注册中心地址全局事务并未开启入口方法没有加GlobalTransactional或 Seata 自动配置未生效查看发起方日志是否有global tx started在全局事务发起方法加注解确认 Seata 相关依赖和配置存在库存扣减成功但订单不生成订单服务和库存服务不在同一个全局事务中检查下游日志是否出现分支事务注册记录确认 XID 通过 Feign 调用传递检查调用链路是否有异常被吞回滚时报 Branch transaction rollback failure业务库缺少undo_log表、表结构不对、业务表无主键查看回滚堆栈定位具体表检查undo_log表是否创建在每个业务库创建undo_log表确认业务表有主键回滚时数据恢复不正确业务表存在其他并发操作前后镜像匹配失败分析全局锁等待日志确认是否有并发修改同一行数据缩短事务时间或结合业务幂等控制并发全局事务运行超时事务方法内包含外部接口、文件处理、网络等待等耗时操作查看 TC 日志中的超时时间检查业务方法耗时将耗时操作移出全局事务增加超时时间启动时提示事务分组找不到 vgroup mapping客户端事务分组没有映射到 Seata Server 集群名检查 Seata 配置中心中的分组映射检查客户端 tx-service-group 拼写在配置中心补充service.vgroupMapping.{group}{cluster}映射这里最容易被忽略的是第二个问题。GlobalTransactional不是放在任何一个方法上都生效它必须放在全局事务的入口方法上也就是跨服务调用的最外层。如果你放在库存服务自己的方法上订单服务调用它时并不会开启全局事务。还有一个常见问题是 Feign 调用时异常被吞掉。如果storage-service抛出异常后被某个全局异常处理器捕获然后返回了一个 200 状态码的 JSONorder-service不会感知到失败全局事务也不会回滚。比较好的做法是让服务间的业务异常以非 2xx 状态码返回或者由 Feign 解码器把业务错误码转换为异常抛出。8. 最佳实践与工程建议Seata 接入项目后真正决定成败的往往是工程细节。我从实际项目角度整理了一些建议。第一事务边界要尽量小。全局事务内部不要包含用户交互、外部 HTTP 调用、短信发送、文件上传等不可控耗时操作。每个服务内部的本地事务时间尽量控制在毫秒级否则全局锁的等待时间会线性上升。能用本地事务解决的就不要升级为分布式事务。第二AT 模式不是没有成本。它在执行本地 SQL 时要写undo_log提交时要删除日志回滚时要根据镜像生成反向 SQL。这个开销对大多数业务是可以接受的但高并发写入同一行数据的场景下全局锁会成为瓶颈。如果业务对某个热点账户、热点商品的并发写入很高需要评估是否改用 TCC或者用消息队列做最终一致。第三undo_log表是回滚的命根子。每个业务库都要创建表名不能改字段结构也不能随意增删。业务表必须有主键否则 Seata 无法锁定具体行数据回滚时也无法精确定位。数据库账号至少需要 SELECT、UPDATE、DELETE、INSERT 操作业务表和undo_log表的权限不要在生产环境使用超级管理员账号跑业务。第四全局事务的隔离性需要业务设计兜底。AT 模式提供了写隔离但默认的读隔离是读未提交级别。也就是说在极端情况下一个事务还没提交另一个事务可能读到它修改的中间数据。如果业务不允许这种脏读需要自己在查询时加SELECT ... FOR UPDATE或者考虑其他一致性更强的方案。第五幂等设计不能省略。Seata 保证的是事务原子性不负责消息重试和接口重复调用的幂等。比如订单服务在全局事务提交成功后如果客户端超时重试同一个订单可能会被创建两次。业务表需要一个业务唯一键比如order_id字段用于防止重复插入。第六监控和演练要纳入日常。Seata Server 的日志中可以看到全局事务提交数和回滚数Nacos 的控制台上可以看到服务健康状态。建议在测试环境定期模拟库存不足、超时、Seata Server 宕机等场景确认系统在回滚时不会把数据弄坏。第七不要把所有跨服务操作都升级为分布式事务。很多场景更适合消息补偿。比如下单后发优惠券用事务消息先写订单再异步发券配合对账任务处理失败记录。这种方式对性能和可用性的冲击更小。Seata 应该在真正需要强一致的业务链路上使用。第八版本的统一和升级要谨慎。Seata 客户端和服务端的版本最好保持一致跨小版本升级前先在测试环境走一遍全链路事务用例。Seata 版本和 Spring Cloud Alibaba 版本之间还有兼容关系不要随意升级其中的某一个。9. 总结与后续学习方向回到开头的问题Seata 是什么它不是一个能把所有分布式事务问题都包办的框架而是一个把跨服务数据一致性问题转化为可工程化处理方案的中间件。AT 模式通过数据镜像和自动补偿让业务代码只需要关心事务边界TCC 模式则给了团队精细控制资源锁和补偿逻辑的能力SAGA 模式适合长业务流程XA 模式在用得上时可以借助数据库能力实现强一致。如果你准备开始实践建议先把本文的 AT 模式示例完整跑通。成功和失败两个场景都验证一遍观察日志和undo_log的行为这是建立分布式事务手感最快的方式。跑通之后再去看 TCC 和 SAGA 的官方示例评估它们与自家业务形态的匹配度。需要记住的是Seata 本身不会消解决分布式带来的所有复杂性真正决定方案上限的是事务边界的设计、异常链路的管理和业务幂等的落地。先把这几件事做好再引入 Seata你会发现分布式事务并没有想象中那么可怕。