第一层先讲本地事务 Transactional基础铺垫先从单体本地事务切入体现基础功底单体服务单库场景我们用 Spring 的Transactional声明式本地事务底层依靠 AOP 实现保证同一个方法内多条 SQL 原子执行要么全部成功、要么全部回滚满足数据库 ACID但它有明确局限只作用于当前服务、单个数据库微服务拆分后跨服务、跨库操作完全管控不了很容易出现半成功半失败的数据不一致这就引出分布式事务解决方案。第二层分布式事务方案一Seata AT 模式注解GlobalTransactional业务里大部分纯 MySQL 数据库操作场用户下单、JSAPI 支付、扣库存、冻结积分我们使用 Seata AT 自动事务模式核心注解GlobalTransactional标记全局分布式事务入口协调多个微服务分支事务AT 全称 Automatic Transaction全自动处理回滚无需手写补偿代码一阶段执行业务 SQL同步生成undo_log回滚日志和业务数据在同一个Transactional本地事务提交二阶段提交直接异步删除 undo_log无需额外操作二阶段回滚读取 undo_log 自动生成反向 SQL恢复数据优点业务侵入极低只需要加全局注解开发效率高短板只能管控 MySQL 这类关系型数据库Redis、微信商户转账 API 这类外部 / 异构资源无法自动回滚回滚时不能主动调用第三方撤销接口资金类高危场景不适用。第三层分布式事务方案二Seata TCC 模式LocalTCCTwoPhaseBusinessAction当业务链路包含 Redis 缓存、商户主动转账给用户调用微信转账 API这类 AT 覆盖不到的场景我们选用 TCC 手动两段补偿模式核心注解LocalTCC标记当前接口是 TCC 分支事务TwoPhaseBusinessAction绑定 Try、Confirm、Cancel 三段方法对应两段式事务三段逻辑定义贴合我们转账业务Try预留资源数据库冻结余额、Redis 写入冻结标识、调用微信转账接口锁定商户资金Confirm业务最终确认真实扣减冻结余额、清理 Redis 缓存Cancel事务回滚释放资源解冻用户余额、删除 Redis 冻结 key、调用微信撤销转账接口追回资金配套防护注解TCCFence解决三大经典分布式问题空回滚Cancel 先到、Try 未执行不会乱加余额造成资损悬挂Cancel 执行完毕后延迟的 Try 请求到达直接拦截不再冻结资金天然幂等重复回调 / 服务重启重试不会重复扣款、重复解冻优缺点优势支持数据库、Redis、第三方支付 API 任意资源资金类核心业务保障强一致性缺点业务侵入高需要手动编写三段补偿代码开发工作量更大。第四层业务选型总结面试加分收尾我们项目两套方案搭配使用兼顾效率与资金安全普通下单、JSAPI 支付、扣库存等仅操作 MySQL 的业务统一用 Seata AT GlobalTransactional开发快商户转账、平台发红包、操作 Redis 缓存 外部资金接口的核心资金场景强制使用 TCC 模式通过TwoPhaseBusinessAction自定义补偿逻辑避免资金亏损。精简背诵版直接口述项目事务分两层单体用Transactional本地事务只能管单服务单库微服务拆分后出现分布式一致性问题分两种方案第一种是 Seata AT 自动事务用GlobalTransactional依靠 undo_log 自动回滚适合纯 MySQL 操作的下单支付场景开发简单但管不了 Redis 和第三方支付接口第二种是 TCC 手动补偿模式通过LocalTCC和TwoPhaseBusinessAction定义 Try-Confirm-Cancel 三段逻辑能同时处理数据库、Redis、微信转账 API 等异构资源搭配TCCFence解决空回滚、悬挂、幂等问题专门用于商户转账这类核心资金场景。