分布式事务方案选型

面试中，我常问候选人一个问题："你的项目用的是什么分布式事务方案？"

80% 的候选人答："Seata AT 模式。"

我追问："为什么选 AT 模式？有没有考虑过 TCC 或 Saga？"

能回答出来的，不到 10%。

分布式事务方案没有银弹。选型的核心是根据业务场景做出权衡。

【架构权衡】分布式事务是架构设计中最复杂的决策之一。每种方案都有优缺点，关键是根据业务的并发要求、一致性要求、实现成本来做出权衡。

一、方案对比总览

方案	一致性	实现复杂度	性能影响	侵入性	适用场景
2PC	强一致	高	高	低	同数据中心
3PC	强一致	高	高	低	同数据中心
TCC	最终一致	高	中	高	跨服务、跨数据库
Saga	最终一致	中	高	中	长链路业务
本地消息表	最终一致	中	低	中	数据库可靠场景
RocketMQ 事务	最终一致	中	低	中	已用 RocketMQ
Seata AT	最终一致	低	中	低	快速接入
Seata TCC	最终一致	高	高	高	高并发场景

二、选型决策树

分布式事务方案选型决策树：

Step 1: 跨服务/跨数据库吗？
├─ 否 → 本地事务即可
└─ 是 → Step 2

Step 2: 是否强一致性要求？
├─ 是 → 2PC/XA
└─ 否 → Step 3

Step 3: 并发要求高吗？
├─ 高 → TCC / Saga
└─ 低 → AT / 本地消息表

Step 4: 已使用 RocketMQ？
├─ 是 → RocketMQ 事务消息
└─ 否 → 其他方案

三、场景化选型建议

场景一：电商下单（高并发）

业务链路：订单 → 库存 → 余额 → 积分

推荐方案：TCC

原因：
├─ 高并发场景，AT 模式的全局锁会成为瓶颈
├─ TCC 可以通过业务层面的 Try 预留减少锁竞争
└─ 库存服务可以实现"冻结"而非"锁定"

TCC 实现建议：
├─ Order TCC：创建待确认订单 / 确认订单 / 取消订单
├─ Inventory TCC：冻结库存 / 扣减冻结库存 / 解冻库存
└─ Balance TCC：冻结余额 / 扣减冻结余额 / 解冻冻结余额

场景二：金融支付（强一致性）

业务链路：转账 → 手续费 → 流水

推荐方案：2PC / XA

原因：
├─ 金融场景对一致性要求极高
├─ 2PC 提供强一致性保证
└─ 接受一定的性能损失

注意事项：
├─ 确保在同一个数据中心内
├─ 配置协调者高可用
└─ 设置合理的超时时间

场景三：长链路业务（多服务）

业务链路：创建订单 → 扣库存 → 扣余额 → 发优惠券 → 发短信 → 发邮件

推荐方案：Saga

原因：
├─ 链路太长，TCC 需要实现大量 Try-Confirm-Cancel
├─ Saga 每个服务只需实现"做"和"撤销"
└─ 发优惠券、发短信等可以设计为"可选补偿"

Saga 实现建议：
├─ 编排器模式（Orchestrator）
├─ 每个服务实现正向和补偿操作
└─ 编排器控制补偿顺序

场景四：快速接入（无感知）

业务场景：快速接入分布式事务能力

推荐方案：Seata AT

原因：
├─ AT 模式对业务代码无侵入
├─ 接入成本最低
└─ 适合 MVP 或快速验证

注意事项：
├─ 高并发下评估性能影响
├─ 必要时切换到 TCC
└─ 注意全局锁的影响

四、落地 Checklist

场景分析：明确业务对一致性、并发能力的要求
方案对比：对比至少 2-3 种方案的优缺点
POC 验证：压测验证方案的性能影响
降级设计：设计方案失效时的降级策略
监控告警：部署分布式事务监控
故障演练：模拟分布式事务失败的场景

#分布式事务方案选型

#一、方案对比总览

#二、选型决策树

#三、场景化选型建议

#场景一：电商下单（高并发）

#场景二：金融支付（强一致性）

#场景三：长链路业务（多服务）

#场景四：快速接入（无感知）

#四、落地 Checklist