分布式事务模式对比

两阶段提交（2PC）

最传统的强一致性方案。

准备阶段：协调者问所有参与者"能不能提交？"，参与者锁定资源回复yes/no
提交阶段：如果都是yes就通知提交，否则回滚
缺点：同步阻塞，协调者单点故障，性能差。现在基本不用了。

TCC（Try-Confirm-Cancel）

把业务逻辑拆成三个阶段：

Try：预留资源（比如冻结库存、冻结余额）
Confirm：确认提交（扣减库存、扣减余额）
Cancel：取消回滚（解冻资源）
优点：不依赖数据库事务，灵活
缺点：业务侵入性强，每个操作要写三套逻辑

例子：转账100元

Try：冻结A账户100元
Confirm：A扣100，B加100
Cancel：解冻A账户100元

Saga模式

把长事务拆成多个本地短事务，每个事务都有对应的补偿操作。

执行顺序：T1 → T2 → T3 → T4
如果T3失败，就执行： C2 → C1（逆序补偿）

优点：简单，每步都是本地事务
缺点：不保证隔离性，中间状态可能被看到

ps: T和C是一对的，每个T（Transaction，正向操作）都要有对应的C（Compensation，补偿操作）。

本地消息表

也叫事务性消息、最大努力通知。

流程：

本地事务中插入业务数据 + 消息记录
提交事务
异步发送消息到MQ
定时任务扫描未发送的消息重试
优点：简单可靠，最终一致
缺点：需要额外的消息表，有延迟

MQ事务消息（RocketMQ/Kafka）

一些MQ自带事务消息功能，原理类似：

发送half消息（对消费者不可见）
执行本地事务
提交/回滚half消息
MQ反查机制兜底
优点：不需要本地消息表
缺点：依赖特定MQ

总结

实际电商场景

本地消息表

Saga补偿（处理退款）

超时取消订单