分布式事务面试题讲解
一、问题背景与解决方案概述
二、Seata 框架关键角色
- 事务协调者（TC）：维护全局和分支事务状态，协调提交或回滚，需单独部署。
- 事务管理器（TM）：定义全局事务范围，负责开启、提交等操作。
- 资源管理器（RM）：每个微服务即一个 RM，代表分支事务，需向 TC 注册并报告状态。
三、Seata 框架 XA 模式
- 流程：TM 开启全局事务后调用分支事务注册到 TC，RM 执行业务 SQL 但不提交，先报告状态给 TC，TM 依据 TC 反馈的分支事务状态决定提交或回滚。
- 特点：保证数据强一致性，属 CP 模式，但性能差，因分支事务需相互等待。
四、Seata 框架 AT 模式
- 流程：TM 开启全局事务并调用分支事务注册到 TC，分支事务执行并提交业务 SQL，同时记录更新前后快照到 undo log，报告状态给 TC，TM 提交或回滚全局事务，TC 检查状态，成功则通知分支事务删除 undo log，失败则依据 undo log 逆向恢复数据。
- 特点：性能较好，为 AP 模式，是官方推荐且开发常用方式。
五、Seata 框架 TCC 模式
- 流程：基于 try（资源检查或预留）、confirm（完成资源操作）、cancel（预留资源释放）三个阶段。TM 开启全局事务并调用分支事务注册到 TC，分支事务进行资源预留操作后报告状态，TM 根据 TC 检查结果提交（执行 confirm 操作）或回滚（执行 cancel 操作）。
- 特点：性能较高，属 AP 模式，但代码耦合度高，需手动编写代码维护三个阶段。
六、MQ 解决分布式事务方案
- 流程（以借呗借钱为例）：借呗审核通过后生成借款单并向 MQ 发消息通知支付宝转账，需确保相关操作在同一事务内运行，否则不发送消息。
- 特点：异步操作性能好但实时性差，保证数据最终一致性，适用于对数据强一致性要求不高的场景，若支付宝增加余额出现异常通常需人工介入。
七、不同方案适用场景与面试应对
- 适用场景：XA 模式和 TCC 模式常用于银行业务；AT 模式和 MQ 方式多用于互联网业务。
