微服务分布式事务Seata全解析：核心原理与实战落地

1. 先搞清楚：Seata到底解决的是什么问题

我见过不少团队，微服务拆分做了一半，订单、库存、账户各自独立成服务，数据库也分了库，结果到了对账环节发现数据对不上——订单扣款成功了，库存却超卖；用户支付了，积分没加上；退款退了一半，剩下的一半找不到了。这时候才想起来：分布式事务怎么搞？

单体时代我们根本不用想这个问题。一个数据库，一个Spring事务管理器，@Transactional一把梭，ACID天然保证。但微服务一拆，一次业务操作往往跨多个服务、多个数据库，原来的本地事务彻底失效。你不可能让订单库和库存库共享一个事务管理器，也不可能靠数据库层面去协调两个物理隔离的数据源。Seata就是专门来解决这个问题的。

Seata的全称是Simple Extensible Autonomous Transaction Architecture，中文一般叫分布式事务框架，由阿里巴巴开源并贡献给了社区。它做的事情可以用一句话概括：让微服务架构下的跨库、跨服务操作，仍然具备类似单体事务的原子性和一致性。注意“类似”这个词，因为分布式环境下，完全等价于数据库ACID的强一致是有代价的，Seata的取舍就是用一套轻量级的机制，在业务无感的前提下把一致性做到工程上可接受。

这篇不是官方文档的搬运，我尽量用做过项目的口吻，把Seata到底是什么、内部怎么运作、开发时到底要干什么这三件事讲透。如果你正准备在你的项目里引入Seata，或者已经在用但某些机制一直糊里糊涂，这篇文章大概率能帮你把脑子里的线头理顺。

先明确三件事：第一，Seata本质是一个框架，不是一个中间件服务那么简单——它确实需要部署一个Server端（TC），但真正复杂的是客户端集成那套逻辑；第二，Seata不是银弹，它有自己的隔离性缺陷、性能开销和适用边界，只有理解这些才能选对事务模式；第三，实际开发要做的绝不只是加一个@GlobalTransactional注解，后面还连着一串事务组配置、回滚规则、全局锁超时、表结构坑、异常处理等问题。

2. 从全局到落地：深入理解Seata的核心架构与事务模式

2.1 三个角色的定义与职责，先别急着写代码

Seata的架构在设计上非常清晰，一共三个核心角色。

TC（Transaction Coordinator）是事务协调者，维护全局事务和分支事务的状态，驱动全局提交或回滚。如果你用的是AT模式（后面会细讲），这个角色就是Seata的服务端seata-server，需要单独部署，运行时会监听两个端口：一个用于服务发现和注册（默认8091），一个用于和客户端通信。

TM（Transaction Manager）是事务管理器，负责开启、提交、回滚全局事务。它嵌入在业务代码中，你写@GlobalTransactional注解的地方，实际上就是在告诉TM：从这里开始，后面的调用链都是同一个全局事务的一部分。

RM（Resource Manager）是资源管理器，管理分支事务中的资源，向TC注册分支，并报告分支执行状态。一个分支事务通常对应一个微服务内部的一个本地事务，比如订单服务里插入一条订单记录、扣库存服务里执行一条update，这些都是分支事务。

一个典型的全局事务流程是这样的：TM向TC申请开启全局事务，拿到一个全局事务ID（XID），这个XID会通过Dubbo、Spring Cloud等框架的拦截器自动传播到后续调用的所有服务；每个服务里执行本地SQL时，RM会通过DataSourceProxy对JDBC数据源做一层代理，自动把本地事务注册为全局事务的分支；最后TM根据业务执行情况向TC发起全局提交或回滚，TC再通知所有RM统一处理自己所属的分支。

这里最核心的设计思想是：Seata把分布式事务拆成了“两阶段”——第一阶段本地提交，第二阶段统一决策。这个思路和传统XA协议的二阶段提交很相似，但实现上做了大量优化和妥协。

2.2 四种事务模式横向对比：AT、TCC、SAGA、XA怎么选

Seata官方提供了四种事务模式，很多初学者一上来就懵了：我到底该用哪个？

AT模式是Seata最推荐、使用最广泛的模式，也是很多项目默认的选择。它的核心特点是对业务代码侵入性最低——你不需要改写原来的SQL，只需要在方法上加上@GlobalTransactional注解，Seata会自动拦截JDBC操作，记录数据快照，生成前后镜像，从而实现分布式回滚。这个方案很适合大部分常规业务场景，缺点是会额外使用一张undo_log表，并且本地事务提交后、二阶段全局回滚前这段时间里，数据处于中间态，存在一定的脏读风险。

TCC（Try-Confirm-Cancel）模式是另一种思路。它把业务操作拆成三个接口：Try阶段尝试执行业务并预留资源，Confirm阶段确认执行业务，Cancel阶段取消预留和释放资源。这个模式做得好的话性能非常高，但需要你手动编写三个方法，业务侵入很大，而且对幂等、空回滚、悬挂这些分布式一致性问题需要做大量防守性代码。我在真实项目里见过不少TCC实现，能把悬挂问题完全处理干净的团队少之又少。

SAGA模式主要面向长流程业务，比如一个订单要经过下单、支付、发货、签收十几个甚至几十个步骤，中途失败就通过一套责任链式的反向补偿操作把之前的步骤全部撤销。它适合流程长、要求最终一致的场景，但补偿逻辑完全是业务定制的，维护成本很高。

XA模式是最传统的一种，基于数据库底层的XA协议，由数据库本身保证分布式事务的原子性。它的优势是一致性最强，缺点是性能差、会对数据库锁占很长时间，而且很多数据库的XA支持性并不好。Seata社区对XA的定位是“兼容性模式”，实际生产环境用得很少。

我个人的建议是：能选AT就选AT，80%以上的分布式事务场景AT都能覆盖。只有当你对性能极端敏感，或者业务要求必须在事务结束前数据一定不能呈现中间状态时，才考虑TCC；只有长流程但要求最终一致的，才考虑SAGA。别把方案选型想得太复杂，过度设计是分布式事务项目最常见的失败原因。

2.3 AT模式的两阶段提交，为什么Seata敢让本地事务先提交

很多刚接触Seata的人都有一个疑问：一阶段就提交本地事务了，万一二阶段要回滚，数据已经写进数据库了怎么办？这就是不明白AT模式回滚机制时最典型的担忧。

一阶段执行的完整流程是这样的。分支事务里执行update account set balance = balance - 100 where id = 1之前，Seata的DataSourceProxy会先解析SQL，查出这条记录当前的数据快照（before image），然后执行SQL，再查出执行后的数据快照（after image）。两张快照连同表名、SQL类型、主键值一起写入本地的undo_log表里，然后再提交本地事务。

这里有个关键点：写入undo_log和业务SQL是同一个本地事务。也就是说，要么业务SQL和undo_log一起提交成功，要么一起回滚，这保证了快照记录和业务数据之间的一致性。

到二阶段，所有分支的本地事务都已经提交成功了。如果TM发起了全局提交，那每个RM只需要异步删除undo_log里的记录就行，这部分没有任何数据变更，非常轻量。如果TM发起了全局回滚，那RM会通过undo_log里的after image，用逆SQL的方式把数据还原成before image，然后删除日志。

你可能会问：一阶段本地提交后，数据已经可见了，其他事务在这个中间态读到了新数据怎么办？这就是AT模式最有争议的薄弱点——默认情况下，AT模式对全局事务内的一个分支，其实是没有严格的隔离性的。它提供的唯一防冲突机制是全局锁：在修改数据时会获取一个基于TC的全局写锁，锁的记录是（资源ID，行主键），如果同一个行记录被两个不同的全局事务同时修改，后者会等待全局锁。但注意，这个锁只约束了“写-写”冲突，“读”操作如果没有被Seata拦截，是可能读到中间态数据的。

很多生产事故就出在这里。比如你有一个查询接口，查询逻辑没走@GlobalTransactional，那它在全局事务一阶段提交后、二阶段提交回滚前的窗口期，就可以读到一条即将被回滚的数据。解决方案有三个层面：一是业务层面接受最终一致性，这是AT模式的默认选择；二是要求所有读操作都走Seata拦截的数据源代理，并把全局锁查询开启，让读也感知全局锁；三是使用SELECT FOR UPDATE由Seata扩展处理。但不管哪种，都会牺牲性能和并发度。因此，AT模式的真正定位是：通过牺牲极短的中间态一致性，换取了业务代码几乎零改动的开发体验。

2.4 全局锁、脏读与脏写：三条必须记住的结论

深入理解AT模式细节后，有三个结论建议大家写进自己的技术笔记里。

第一，AT模式能防脏写，不能完全防脏读。全局锁保证了同一行数据不会同时被多个全局事务修改，所以不会发生A事务覆盖了B事务未提交数据这种脏写问题。但普通读操作绕开了锁机制，你仍然有可能在事务二阶段前读到目标行的中间态。如果你的业务对这点很介意，请考虑TCC或者直接牺牲并发能力开启全局读锁方案。

第二，全局锁等待超时时间是可以配置的。默认的client.rm.lock.retryInterval是10毫秒，client.rm.lock.retryTimes是30次，整体算下来最多等待300毫秒。在高并发争抢同一行记录时，300毫秒可能不够用，这个参数在实战里经常被调大，但不是越大越好——越大意味着事务整体阻塞时间越久，最终牺牲的还是吞吐量。

第三，二阶段回滚依赖于undo_log里快照的准确性。一旦你的SQL里用了now()、random()、uuid()这类非确定性函数，after image和before image可以正常记录，但逆SQL执行时会发现数据永远还原不到事务前的状态——因为时间戳和随机数已经变了。这是AT模式一个隐蔽的坑，后面实操部分我会再强调。

这三种模式之间的取舍，本质上是一致性、性能、侵入性这个不可能三角在具体场景下的再平衡。理解了这一点，你在实际项目里做技术选型时就不会纠结太多。

3. 实际开发要做的事情清单：从零接入Seata到稳定落地

3.1 TC服务端部署：下载、启动和配置文件的几个必改项

先明确一个概念：Seata的应用分两端，服务端叫seata-server（即TC），客户端是集成进业务服务里的SDK。很多初学者搞不清这个边界，以为在pom里引入了依赖就能用，结果怎么弄都是注册失败——因为根本没启动服务端。

部署TC的步骤很简单。去GitHub的Seata Release页面下载对应版本的服务器压缩包，解压后进入bin目录，执行sh seata-server.sh -p 8091 -h 127.0.0.1 -m file即可启动一个最简易的单机TC。其中-m file表示使用文件方式存储事务会话日志，适合开发和测试；生产环境我会建议用-m db模式，把全局事务会话信息持久化到数据库里，否则TC一重启，未完成的事务状态直接丢了，极端情况下会造成全局锁一直不释放。

配置文件的必改项方面，早期版本是registry.conf和file.conf两个文件，新版本（1.4+以后）拆成了application.yml。核心要确认三件事：

• registry下的type，默认是file，意思是客户端通过本地文件直连TC地址。如果你们用Nacos做服务发现，可以改成nacos并配置对应的serverAddr和namespace，这样一旦TC做了多机扩容，客户端能自动感知。
• config的数据源，同样有file和nacos两种选项。如果使用file，所有配置在本地application.yml改即可；如果使用nacos，配置将集中在配置中心，改动不用重启服务，但需要把配置文件内容上传到Nacos配置列表里。
• 事务日志存储方式。前面说的store.mode要确认是file还是db，如果用db，需要在数据库建global_table、branch_table、lock_table三张表。建表SQL在GitHub的script/server/db目录下都能找到，直接执行就行。

我踩过的一个坑是版本问题。TC端和客户端SDK版本必须保持一致，否则会出现RPC协议不兼容、注册失败、事务状态上报异常等千奇百怪的问题。不要图方便随便降版本，我建议先定好版本号，服务端和所有业务服务统一使用同一个。

3.2 客户端依赖、配置和全局事务扫描：不写错的细节

服务端准备好了，接下来就是业务服务集成客户端。

Maven依赖没什么特别，在pom.xml里引入对应的seata-spring-boot-starter，版本和服务端保持一致。如果你用的是Dubbo，则额外引入seata-dubbo适配包；如果你用的是Spring Cloud OpenFeign，大部分时候starter已经帮你处理好了。

然后是application.yml配置。需要写清的配置项包括：

seata: enabled: true application-id: order-service tx-service-group: my_test_tx_group enable-auto-data-source-proxy: true service: vgroup-mapping: my_test_tx_group: default grouplist: default: 127.0.0.1:8091

看到tx-service-group和vgroup-mapping这两个概念，很多新手第一次会卡住。事务服务分组是逻辑上的一层映射：你的业务服务标识自己属于哪个事务分组，然后由这个映射找到真正要连接的TC真实地址。这么设计的主要目的是方便在部署层面做TC的灰度、多活和故障切换——客户端只知道分组名，不感知具体TC实例地址。生产上我建议把这个分组名起得有业务区分度，比如order_tx_group、payment_tx_group，别所有服务都用一个组，不然后期做分片管理时无从下手。

还要注意一个细节：enable-auto-data-source-proxy默认是true，这个开关负责把你的DataSource包装成Seata的代理数据源。如果你在项目里手工配置了多个DataSource或者有特殊的数据源路由逻辑，这个代理可能会不生效或绕过，导致分支事务注册不上，全局事务回滚时发现少了一环。多个数据源的项目里一定要单独验证。

事务边界定义是更关键的一件事。全局事务的开启并不是“只要加了注解就行”，而是完全依赖Spring的AOP。@GlobalTransactional注解加在Spring管理Bean的public方法上时，TM会在方法执行前开启全局事务，方法执行后根据是否抛出异常决定提交或回滚。但这个拦截器依赖的代理机制有自身的生效限制，你在实际开发时需要注意：不要加在private方法上；不要通过同类方法的内部调用去触发（比如this.method()，这样AOP代理根本不会拦截）；最好加在服务层的门面方法上而不是Controller层——Controller只负责参数校验和返回结果，事务边界应该放在实际业务逻辑的入口处。

3.3 undo_log表、回滚规则和业务SQL的限制

如果是AT模式，每个参与分布式事务的业务数据库里都要建一张undo_log表。这张表的官方建表SQL长这样：

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`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

这里值得提醒的是，undo_log是Seata自动写入用的，千万别在业务代码里碰它，也千万别在数据库层面手动删它里的数据。表里保存的就是回滚所需的前后镜像，一旦缺了，二阶段回滚时Seata连执行逆SQL的凭据都没有。

接下来是回滚规则。默认情况下，只要方法抛出任何异常，全局事务就会回滚，无论什么异常类型。但如果你在代码里自己catch了异常、没有继续抛出，那全局事务感知不到失败，会正常提交——这可能是最容易被忽略的一个问题。

什么叫自catch异常？举个例子：

@GlobalTransactional public void createOrder(OrderDTO dto) { try { orderDao.insert(dto); inventoryService.deduct(dto.getSkuId(), dto.getCount()); accountService.debit(dto.getUserId(), dto.getAmount()); } catch (Exception e) { log.error("createOrder failed", e); } }

这种情况下，即使库存扣减失败了，异常也被吞掉了，Seata的TM拿到的是正常返回，于是发起全局提交。结果就是：订单建了、库存没扣、账户没扣钱。很多线上数据不一致事故的根源就是这种“try-catch吞异常”写法。正确做法是：在@GlobalTransactional标记的方法里，要么不catch异常，要么catch之后重新抛出RuntimeException。如果要catch住做补偿逻辑，就需要在catch块内显式调用GlobalTransactionContext.reloadCurrent()并调用rollback()手动回滚，但这种做法非常容易出错，我的建议是尽量不用。

另外，AT模式对SQL有隐性限制。比如不能使用INSERT INTO ... SELECT这种不确定来源的写法；不能使用UPDATE语句带LIMIT；强烈避免在事务中混用非事务表（比如MyISAM表，它不支持undo_log和本地事务联动）；前面也提到了now()这类非确定性函数会导致回滚数据对不上。你会遇到这些问题时往往是在灰度发布后被QA和监控发现，与其事后查，不如开发阶段就做一轮SQL review，把这些写法全部调整掉。

3.4 全局事务挂接与跨服务透传：拦截器和XID传播

分布式事务和单体事务最大的区别之一就是：全局事务的范围跨越了服务调用链，而Seata要让你在每个服务里感觉不到这个跨越。

它靠的是XID的传播。TM开启全局事务后会把全局事务ID放到当前调用上下文里，然后通过RPC层的拦截器把XID传递到下游服务。OpenFeign是SeataFeignClient，Dubbo是TransactionPropagationFilter，RestTemplate则要自己确认是否被适配。这些拦截器都会自动把XID从请求A附加到下游调用的请求B中，下游服务收到XID后，会自动把本地的事务分支注册到同一个全局事务下。

开发时常见的错误是自己手动封装Feign配置或者自定义了RestTemplate拦截器，把Seata自带的拦截器绕过了。这时候你查Seata日志未必看到明显的报错，但全局事务列表里就只有最上层服务一个分支，下游操作全部脱离控制。排查这类问题我一般用两个手段：一是打开seata日志包为DEBUG级别，看分支注册的输出；二是在数据库branch_table里查当前全局事务ID对应的记录数量，数量对不上就说明有服务没接上。

还有一种更隐蔽的问题：异步线程里用XID。比如你在@GlobalTransactional方法里用CompletableFuture.runAsync()开了一个异步子任务去调下游服务，这个子任务默认是拿不到当前线程的XID的。需要在父线程里手动获取RootContext.getXID()，然后在子线程里再RootContext.bind(xid)。我见过有团队在异步场景下丢配置，排查花了一整天，最后发现就是XID没有传递到子线程里导致分支无法关联。

还有一种是MQ场景的最终一致性。这个其实不是Seata的强项，因为异步消息的事务边界和同步RPC链路的处理方式不一样。如果业务上一定要用MQ，我建议把它放在全局事务的最后端，事务成功后通过afterCommit模式发MQ消息，避免在Seata事务内部直接发MQ导致消息发送和事务提交不一致。

3.5 事务模式切换与性能调优的实用参数

如果你最终选用了AT模式，想在生产环境稳定运行，有几个参数值得在压测时一起验证。

client.rm.lock.retryInterval和client.rm.lock.retryTimes控制全局锁重试策略，默认总等待时间300毫秒。建议压测时观察业务日志里有没有频繁出现Global lock acquire failed或者等待全局锁的WARN级别日志，如果有，把retryTimes调到60甚至更高，同时调整对应接口的超时时间。

client.tm.commitRetryCount和client.tm.rollbackRetryCount控制TM向TC发起全局提交/回滚时的重试次数。分布式环境里网络抖动是常态，TC收到请求但响应报文丢了的情况很常见，这两个参数官方默认都是5次，重试间隔大概5秒。真正需要调整的场景是网络质量较差、TC偶尔不可用的集群，但这里的注意点是：重试提交可能造成重复提交，重试回滚可能造成重复回滚，好在Seata对分支提交是幂等处理的，重复执行不会产生破坏性后果。

transport.heartbeat相关配置则和连接保活有关。老版本里出现过长连接空闲断开后客户端不自知，导致异步分支事务的提交请求发不出去的案例。新版本Seata默认15秒心跳，如果你的业务服务经常有超过15秒的间隙没有请求，这个默认值通常够用。

性能调优的一个核心指标是：单次分布式事务里分支事务的数量尽量不要太多。分支数量越多，TC需要协调的资源就越多，网络往返和数据库日志写入也越多。我建议每个全局事务控制在一个服务调用链的3~5个分支以内，超过这个规模的业务逻辑，优先审视一下是不是事务边界划得太大了。一个常见误区是把无关紧要的查询、计算都塞进全局事务里，这会白白增加锁的范围和持有时间。

4. 实操中高频踩坑问题与排查技巧

4.1 常见问题的现象、原因和解决方案速查表

我把自己在项目里遇到的、以及身边团队经常反馈的问题整理成了下面这张表，遇到问题时可以先对着排查。

4.2 两个最容易被人忽视的隐性坑

第一个是新建的undo_log表字符集问题。如果业务库默认字符集是utf8mb4，而建表语句里没指定，rollback_info这种longblob类型字段本身不依赖字符集，倒没什么问题。但如果你把表建在了别的库，就会遇到分支事务执行时报找不到undo_log表——因为Seata使用的数据源和业务数据源并不一定一致。这里要特别确认：当你有多个业务库时，每一个可能参与分布式事务的库都要建这张表。只建一个库就完事的做法一定有问题。

第二个是服务的幂等性问题。Seata的回滚虽然是靠undo_log自动执行的，但二阶段提交本身是异步的、带重试的。当TC向RM发了一个分支回滚请求，RM由于网络超时没来得及响应，TC会重试；此时如果客户端已经把本地事务的undo_log删除了，重试就可能出现找不到日志的情况。Seata内部有自己的幂等保护，不会让数据重复回滚，但你的业务接口一定要做好幂等处理，否则一旦用户连续提交两次订单，两次全局事务各自独立，就可能出现重复扣库存、重复建订单的问题。分布式事务保证的是“一次操作要么全部成功要么全部回滚”，它不负责把客户的重复点击合并成一次操作。这是初级团队最容易误解的地方。

4.3 日志、监控和排查分布式事务的实用手段

排查Seata问题时，第一手资料是日志。客户端日志需要在日志配置里把io.seata这个package的级别设为DEBUG，才能看到分支事务注册、全局锁获取、二阶段响应这些关键节点。服务端TC也有自己的日志，一般在seata-server运行的logs目录下，排查问题是两边日志要一起看。

监控方面，如果TC使用DB模式存储，最有用的排查手段是直接查global_table和branch_table。比如你怀疑某个全局事务一直没结束，就查global_table看status字段：0表示begin，1表示committed，2表示rollbacked，3表示timeout。如果长时间停在0，说明这个事务一直挂着，要看是不是下游分支一直没响应或者全局锁等待卡死。

还有一个值得养成的习惯：在核心业务入口打印全局事务XID。你可以在@GlobalTransactional方法里加一行RootContext.getXID()的INFO级别日志，这样排查问题时只要根据订单号找到日志，就能拿到XID，再拿XID去查全局表和分支表，整个调用链的状态一目了然。没有这行日志，出了事你只能靠时间去猜，效率差别非常大。

4.4 集成测试和灰度发布的建议顺序

Seata这类分布式事务组件，最忌讳的是直接在所有服务上一次性全量开启，出了问题都不知道是哪个环节引起的。我建议按下面这个顺序来推进落地。

第一步，先在两个最简单的服务上做证明性测试：一个服务作为发起方，一个服务作为下游执行方，分别只做一次普通表插入操作，验证全局事务能正常提交和回滚。这一步能排除80%的配置问题。

第二步，把真实业务引入，但先用影子表或者测试环境做全链路压测，重点关注全局锁等待时间、分支数量、undo_log增长这三项指标。

第三步，灰度发布时选择一条流量占比低但是业务完整的链路，并且在监控上把Seata相关的指标单独看板展示，观察至少一个完整业务周期的数据一致性。

第四步，全量放开前，和DBA确认数据库连接池大小、undo_log表磁盘增长预期、TC服务器内存和连接数上限，做好容量规划。

我见过太多团队在第一步都没走完的时候就直接生产全量接入，结果一上线就遇到大面积的全局锁等待超时，业务直接雪崩。分布式事务组件本质上是在抢数据库连接、抢行锁、抢网络资源，它带来的额外开销一定会在压力测试里显现出来，提前摸清底数比事后补救划算得多。

5. 一段关于选型和个人经验的实话

最后分享一下我在实际项目里的体会。

Seata其实不是一个“装上就能用”的组件，它更像是一种“业务一致性架构”的落地方式。你在项目里引入Seata，看起来只是加了一个注解、几张表、一个服务端，但实际上是在向团队表达一种约束：事务边界要清晰、异常要传递、SQL要规范、幂等要做好。undo_log表是Seata在管，但SQL里不能用非确定性函数、接口要支持重复调用、异常不能被吞——这些是团队自己要做到的。

我的建议是，如果你团队里还没有统一的异常处理规范，先把这一层做好，再上Seata，否则你会发现自己每天不是在排查业务问题，而是在排查为什么Seata没有按你想象中那样回滚。反过来，如果你团队规范已经成型，Seata会让跨服务的数据一致性问题变得像处理本地事务一样顺手，这就是这个框架最大的价值。

还有一个务实的提醒：分布式事务是有成本的，不要为了“技术感”而引入。如果你的业务里只是在两个服务之间同步调一次接口，完全可以用本地消息表、事务消息或者简单的重试加对账来保证最终一致性，未必需要上Seata。Seata的定位是：多服务、多库、强一致性要求高、无法用异步消息替代的场景。想清楚自己是不是真的需要它，再动手，这比学会怎么配它重要得多。

如果看完这篇文章你想开始动手，建议先把官网快速开始文档里的demo跑通一遍，然后对照这篇文章把undo_log表、事务组配置、全局锁超时参数等每个细节都过一遍，这样踩坑的概率会小很多。