分布式事务Seata使用？真实项目总结

▌ 技术引导
在真实项目中，Seata的使用关键在于把分布式事务的复杂性封装成可控的模块。我见过多个团队用Seata实现多数据源下单、库存扣减、支付对账等场景，但真正稳定落地的只有少数几个。核心问题集中在事务分支的划分、TC节点的高可用、事务日志的清理策略以及性能损耗的评估上。我踩过的坑包括事务未正确回滚、TC集群宕机导致事务卡住、XA模式下数据库不兼容、日志文件堆积影响磁盘空间。真实项目中，使用Seata的TC集群部署在K8s上，通过阿里云的容器服务进行高可用配置，同时结合Prometheus监控事务状态，能第一时间发现异常。配置文件中要特别关注事务分组、事务超时时间、重试策略，避免因为参数设置不当导致系统不稳定。如果想做到真正稳定，必须结合本地事务和全局事务的边界控制，还有对异步消息的补偿机制进行深度打磨。

▌ 技术参考

一 在实际部署中，Seata的TC服务需要独立部署，并且必须保持高可用。我们项目中采用的是Seata Server+MySQL+Redis的组合，TC服务部署在K8s上，并通过阿里云的容器网络实现跨集群通信。配置文件中要指定seata.server.port=8091，确保端口不冲突。同时，在集群节点之间使用seata.service.vgroupMapping.default_tx_group=cluster1这样的配置，保证事务分组匹配。如果发现TC服务频繁挂掉，可能是资源不足或者网络隔离问题，检查容器的内存和CPU使用情况，以及服务间的调用链路。

二 使用Seata的事务分支划分时，必须关注每个微服务的事务参与者角色。比如，订单服务是TC，库存服务是RM，支付服务是RM。在每个微服务的配置中，需要设置seata.tx-service-group=tx-group-name，确保事务分组一致。对于高并发场景，我们发现默认的全局事务超时时间8000毫秒不够，改成了12000毫秒。这里有个小技巧，可以在seata.conf中调整transaction.default.timeout=12000，避免因为超时导致事务无法正常提交。另外，在TransactionContextManager里要确保全局事务的传播行为正常，不能出现事务嵌套错误。

三 在生产环境中，Seata的事务日志清理是必须关注的问题。我们项目中使用的是AT模式，每次事务提交都会生成一个Undo Log，存储在MySQL数据库里。如果不及时清理，日志文件会快速膨胀，导致磁盘空间不足。在seata.conf中，配置undo.log.table=undo_log，确保日志表名正确。然后设置undo.log.delete-at=120000，表示120秒后自动清理。对于大型项目，还要考虑日志清理策略和磁盘IO性能，否则会影响整体事务处理效率。另外，如果事务分支太多，建议使用分库分表的方式，避免单表压力过大。

四 在应用层，使用Seata的@GlobalTransactional注解时要格外小心。我见过几个团队因为没有在方法入口处正确标注这个注解，导致事务未被正确管理。比如，数据库操作和RPC调用混用，容易造成事务边界模糊。正确的做法是在订单服务创建订单的方法上加@GlobalTransactional，然后在库存和支付服务中通过@TwoPhaseBusinessAction注解进行业务逻辑封装。在启动时，需要确保Seata的starter组件正确引入，并且配置了seata.client.naming.type=nic，避免因为服务发现问题导致事务无法注册。

五 在网络不稳定的情况下，Seata的事务可能会出现超时或者异常。我们项目中在南美和东南亚的节点上，经常遇到跨地域调用延迟高导致事务超时的问题。解决方案是调整seata.client.rm.async-commit-interval=5000，延长事务提交间隔，同时开启seata.client.rm.report.success.enabled=true，确保即使事务超时也能被正确记录。此外，使用OpenFeign调用时，需要配置feign.client.config.default.connectTimeout=5000，feign.client.config.default.readTimeout=5000，避免因为网络问题引发事务异常。这部分配置虽然简单，但对稳定性影响极大。

六 在Seata的事务回滚过程中，如果某个RM节点宕机，全局事务可能会卡住。我们遇到过一次大规模的分布式事务阻塞，原因是某个库存服务的数据库连接池配置不合理，导致事务无法回滚。排查后发现，seata.conf中RM的配置项seata.client.rm.transaction.undo.log.maintain-time=120000，这个参数控制的是undo log的保留时间，如果过短，可能在回滚前就被删除了。我们把该参数调大，并且在RM节点上增加了心跳检测，确保服务正常运行。同时，对事务分支进行监控，及时发现异常分支。

七 在使用Seata的XA模式时，数据库必须支持XA协议，比如MySQL 8.0以上版本。我们项目中曾经因为数据库版本过低，导致XA模式下的事务无法正确提交。解决方式是强制升级数据库版本，同时在seata.conf中设置seata.client.rm.transaction.xa.tm-type=AT，确保使用的是AT模式。对于XA模式下的事务，事务日志的清理和回滚依赖于数据库的XA事务日志，所以要特别关注数据库的配置和性能。此外，XA模式下的性能通常不如AT模式，需要做好压力测试和调优。

八 在实际应用中，Seata的事务日志存储方式对性能有直接影响。我们项目中在MySQL中使用了undo_log表，但发现随着业务增长，这个表的写入压力变得很大。于是我们尝试使用本地文件存储，通过seata.client.rm.transaction.undo.log.maintain-time=120000来控制日志保留时间。同时配置seata.client.rm.transaction.undo.log.table=undo_log，避免日志表名冲突。在日志清理方面，我们开发了一个定时任务，定期扫描和清理过期的日志记录，确保磁盘空间不被耗尽。这个方法虽然简单，但能有效降低数据库压力。

九 在Seata的事务协调过程中，经常会出现事务分支未被正确提交或回滚的情况。我们项目中遇到过一次订单服务提交成功，但库存服务回滚失败的问题，最终是发现库存服务的事务分支没有正确注册。排查发现，seata.conf中的seata.client.rm.async-commit-interval=5000参数没有生效，导致事务分支注册延迟。调整后，事务分支注册变得及时，整个事务流程也更加稳定。在应用层，我们通过TransactionContextManager来管理事务上下文，确保每个服务都能正确获取TransactionId。

十 在多数据源的场景下，Seata的事务管理需要特别留意数据源的配置。我们项目中使用了MySQL和Oracle两个数据源，分别配置了不同的事务分组。通过seata.client.rm.transaction.undo.log.table=undo_log，我们确保每个数据源的undo log存储在各自的数据库中。这样做的好处是避免不同事务日志之间的干扰，但增加了配置复杂度。同时，要确保所有数据源的连接参数正确，比如url、username、password，否则会导致事务无法正常提交。这部分配置需要在每个微服务的application.yml中单独设置。

十一 在Seata的事务日志监控方面，我们搭建了一个简单的Prometheus+Grafana监控体系。通过配置seata.metrics.reporter=zipkin，我们能实时跟踪事务的调用链路和状态。在日志清洗过程中，我们发现有些旧事务日志没有被及时清理，导致磁盘空间紧张。于是我们编写了一个shell脚本，定期清理undo_log表中超过120秒的记录，命令是DELETE FROM undo_log WHERE gmt_create < NOW() - INTERVAL 2 MINUTE。这个脚本可以在crontab中设置定时执行，确保日志不会堆积。

十二 在使用Seata的事务补偿机制时，需要特别关注异步消息的可靠性。我们项目中曾经因为消息未被正确发送，导致补偿失败。所以我们在支付服务中增加了消息重试机制，使用RabbitMQ的死信队列来处理重复消息。同时，在事务结束时，通过seata.conf中的seata.client.rm.async-commit-interval=5000来控制事务提交的频率，避免消息堆积。在补偿逻辑中，使用try-catch块来捕获异常，并在finally中确保补偿操作被执行，否则可能造成数据不一致。

十三 在Seata的事务日志恢复过程中，如果数据库重启导致undo log丢失，整个事务流程会被中断。我们项目中遇到过一次数据库主从切换，导致undo log未被正确复制。解决方案是确保MySQL的binlog格式为ROW，同时配置seata.client.rm.transaction.undo.log.maintain-time=120000，保证日志在主从切换后不会被清理。另外，定期备份undo_log表到其他存储介质，比如HDFS或者云存储，能有效防止数据丢失。这部分配置需要在每个微服务的application.yml中单独设置。

十四 在Seata的分布式事务中，事务的隔离级别和传播行为对系统稳定性至关重要。我们项目中某个支付服务因为事务传播行为设置错误，导致多个事务相互干扰。调整后使用seata.client.rm.transaction.undo.log.table=undo_log，确保每个事务都有独立的undo log表。同时，在应用层通过@GlobalTransactional注解控制事务的传播行为，比如设置propagation=NEVER，避免事务嵌套问题。这部分配置需要在每个微服务的配置文件中单独设置，否则容易出现事务管理混乱。

十五 在使用Seata时，如果事务分支数量过多，会影响性能。我们项目中某个订单服务在高峰期出现事务阻塞，最终排查发现是事务分支过多导致TC节点压力过大。解决方案是优化微服务之间的调用逻辑，减少不必要的事务分支。同时，在seata.conf中设置seata.server.session.expire-time=180000，控制事务会话的生命周期。这能有效减少TC节点的负担，提高事务处理的效率。此外，使用异步提交和补偿机制也能降低事务同步带来的性能开销。