分布式事务方案：Seata XA、AT、TCC 与 MQ

只要一个业务操作同时写多个服务的数据就会遇到分布式事务问题。比如下单要写订单、扣库存、扣余额任意一步失败都可能造成数据不一致。一句话概括Seata 通过 TC、TM、RM 协调全局事务和分支事务XA 追求强一致但性能差AT 通过 undo log 提升性能TCC 通过业务代码完成 Try/Confirm/CancelMQ 通过异步消息实现最终一致。是否用户发起业务请求TM 开启全局事务调用多个微服务RM 注册分支事务执行各自本地事务向 TC 报告分支状态所有分支是否成功TC 通知提交TC 通知回滚Seata 三个角色角色全称作用TCTransaction Coordinator事务协调者维护全局事务和分支事务状态TMTransaction Manager事务管理器定义全局事务范围发起提交或回滚RMResource Manager资源管理器管理分支事务资源注册和汇报分支状态可以这样理解TM 是发起人。RM 是各个服务里的执行者。TC 是总协调者。XA 模式XA 是强一致思路偏 CP。全部成功有失败一阶段RM 注册分支事务执行业务 SQL但不提交报告执行状态给 TCTC 检查所有分支二阶段通知提交二阶段通知回滚RM 提交本地事务RM 回滚本地事务优点是强一致缺点是资源锁定周期长性能较差。适合对一致性要求极高的场景。AT 模式AT 也是两阶段模型但一阶段会直接提交本地事务并记录undo log。流程RM 注册分支事务。记录更新前后的数据快照也就是undo log。执行业务 SQL 并提交。报告事务状态给 TC。二阶段提交时删除undo log。二阶段回滚时根据undo log恢复数据。AT 相比 XA资源锁定时间更短性能更好适合很多互联网业务。AT 模式里有两个容易被问深的点undo log和全局锁。机制作用undo log保存修改前后的数据快照二阶段回滚时用来恢复数据全局锁防止多个全局事务同时修改同一行数据避免回滚时数据被别人改乱AT 回滚大概是这样提交回滚否是一阶段执行业务 SQL记录 before image修改前快照记录 after image修改后快照提交本地事务全局事务结果删除 undo log校验当前数据是否等于 after image数据是否被脏写用 before image恢复数据需要人工处理或重试所以 AT 不是“魔法回滚”它依赖快照、全局锁和数据校验。这个点讲出来分布式事务的回答会厚很多。TCC 模式TCC 需要业务自己实现三个阶段阶段含义Try检查并预留资源Confirm真正完成资源操作Cancel释放预留资源是 Try 的反向操作TCC 性能较好但开发成本高。因为每个业务都要写 Try、Confirm、Cancel还要处理幂等、空回滚、悬挂等问题。TCC 里这三个坑尤其要记问题含义处理思路幂等Confirm 或 Cancel 可能被重复调用用事务状态表或唯一业务号防重复空回滚Try 没执行成功Cancel 却被调用Cancel 里先判断是否有 Try 记录悬挂Cancel 先到Try 后到Try 执行前检查是否已经 Cancel简单说TCC 性能好但不是加三个方法名就完了。它把一致性控制更多交给业务代码所以业务状态表、幂等控制和异常分支处理都要自己设计。MQ 最终一致MQ 方案通常用于最终一致场景。比如借款业务支付宝服务审核通过。本地事务里生成借款单。同一个事务内发送 MQ 消息。借呗服务消费消息。借呗服务执行自己的本地事务。消费失败时重试或进入补偿流程。MQ 方式性能最好但不是强一致它依赖消息可靠投递、消费幂等和补偿机制。方案怎么选方案一致性性能开发成本适合场景XA强一致较差较低银行、资金强一致AT最终一致倾向较好较低常见互联网业务TCC最终一致倾向较好高复杂业务资源预留MQ最终一致最好中等异步解耦、通知、跨服务写面试回答模板可以这样答我们项目中只要涉及多个服务之间的写操作就要考虑分布式事务。Seata 里有三个角色TC 是事务协调者维护全局事务和分支事务状态TM 负责开启、提交或回滚全局事务RM 管理分支事务资源并向 TC 注册和汇报状态。Seata 有 XA、AT、TCC 等模式。XA 是强一致两阶段中一阶段执行 SQL 但不提交二阶段统一提交或回滚性能较差。AT 模式一阶段提交本地事务并记录 undo log回滚时用 undo log 恢复性能更好。TCC 需要业务实现 Try、Confirm、Cancel。MQ 方案是异步最终一致性能最好但要保证消息可靠和消费幂等。小结分布式事务不要只背方案名。先问业务需要什么强一致、最终一致、性能、开发成本、失败补偿能力。把这个取舍讲清楚方案选择才站得住。