分布式事务选型：从 2PC 到 Seata 的完整方案

讲述链条

2PC/3PC 原理与缺陷 → TCC 手动补偿 → SAGA 长事务 → Seata AT 自动补偿 → 生产环境决策树

核心表述

分布式事务分为**强一致性（CP）和最终一致性（AP）**两大类。强一致性包括 2PC/3PC、XA 协议和 Seata AT 模式；最终一致性包括 TCC、SAGA、事务消息（RocketMQ）。

2PC（两阶段提交） 分为准备阶段和提交阶段。准备阶段 TC（Transaction Coordinator）向所有 RM（Resource Manager）发送 Prepare，RM 执行本地事务并锁定资源但不提交，返回 YES。提交阶段 TC 收到全部 YES 后发送 Commit，RM 提交本地事务。致命问题：同步阻塞性能差（RT 高），TC 单点故障导致资源锁死，阶段二 TC 故障可能部分 RM 提交部分未提交造成数据不一致。

3PC（三阶段提交） 增加 CanCommit 询问阶段（不锁定资源）和超时机制，RM 超时未收到 DoCommit 自动提交降低阻塞，但依然无法完全解决网络分区场景的数据不一致。

TCC 是业务层面的分布式事务，需要实现 Try（资源预留/冻结）、Confirm（确认提交）、Cancel（取消回滚）三个接口。性能好（不长时间锁定资源），但业务侵入性强，开发成本高（三个接口 + 幂等性）。

SAGA 适用长事务链，每个步骤都有补偿操作。正向流程依次执行服务 A→B→C→D，失败时逆向执行补偿操作回滚。中等侵入性，适合长流程场景。

Seata 框架提供四种模式：AT（自动补偿，基于 2PC 改进）、TCC（手动补偿）、SAGA（长事务编排）、XA（标准 XA 协议，性能最差）。

Seata AT 模式最常用，核心是 Undo Log 自动补偿机制。执行本地事务时 Seata 自动解析 SQL，保存前镜像（执行前数据）和后镜像（执行后数据），提交本地事务并注册分支到 TC。全局事务成功则异步删除 Undo Log；全局事务失败则根据 Undo Log 自动生成反向 SQL 回滚，实现最终一致性。优点是业务无侵入，性能好，适用通用场景。

生产环境决策树：优先避免分布式事务，采用业务拆分实现最终一致性。必须使用时，单数据库 + MQ 用 MQ 事务消息（RocketMQ 半消息机制），多数据库/MQ 用 Seata AT 模式，高性能场景用 Seata TCC 模式，金融核心场景用 XA 模式（牺牲性能）。核心原则：能用 MQ 事务消息就不用分布式事务（性能更好），能用最终一致性就不用强一致性（分布式系统常态），分布式事务是最后手段（复杂度高、性能差）。

数据迁移双写为什么不需要分布式事务？ 因为是临时状态，写入失败加入重试队列后续补偿，允许短暂不一致。缓存更新场景用 Canal + Binlog 或延迟双删 + 最终一致性即可，不需要强一致性。只有金融场景（支付 + 订单 + 库存）等要求强一致性时才需要 Seata 分布式事务。