除了2PC，还有哪些分布式事务解决方案?
1 个赞
除了 2PC（两阶段提交），常见的分布式事务解决方案还有很多，下面按类别进行介绍：
3PC（三阶段提交）
2PC 的改进版本，将原来的"准备阶段"拆分为 CanCommit → PreCommit → DoCommit 三个阶段，并引入了超时机制，降低了参与者和协调者同时阻塞的风险。但仍然存在同步阻塞和单点故障问题。
TCC（Try-Confirm-Cancel）
业务层面的两阶段提交，将事务拆分为三个步骤：
- Try：资源预留和业务检查
- Confirm：确认执行业务，不做任何业务检查，只使用 Try 阶段预留的资源
- Cancel：取消执行，释放 Try 阶段预留的资源
优点：无长时间锁资源，性能好；缺点：业务侵入性强，需要为每个服务编写 Try/Confirm/Cancel 三个接口。
Saga 模式
将一个长事务拆分为多个本地短事务，每个本地事务都有对应的补偿操作。如果某一步失败，则按逆序执行之前已完成事务的补偿操作。
- 编排式（Choreography）：各服务通过事件驱动自主协调
- 协调式（Orchestration）：由一个中央协调器统一调度各步骤
优点：无需全局锁，适合长事务；缺点：隔离性较弱，可能出现"脏读"。
本地消息表
将消息和业务数据写在同一个本地数据库事务中，通过定时任务或轮询将消息投递到消息队列，下游服务消费消息完成最终一致性。
优点：实现简单，可靠性高；缺点：需要额外维护消息表，有一定延迟。
事务消息（如 RocketMQ 事务消息）
消息中间件原生支持的事务消息机制，流程为：
- 发送半消息（Half Message）到 MQ
- 执行本地事务
- 根据本地事务结果，向 MQ 发送 Commit 或 Rollback
优点：由 MQ 保证消息可靠投递，减少业务代码复杂度。
最大努力通知
适用于对一致性要求不高的场景（如支付结果通知）。发起方尽最大努力将结果通知给下游，配合重试 + 对账机制保证最终一致性。
优点：实现简单；缺点：一致性保障最弱。
方案对比总结
| 方案 | 一致性 | 性能 | 业务侵入性 | 适用场景 |
|---|---|---|---|---|
| 2PC | 强一致 | 低（同步阻塞） | 低 | 数据库层面跨库事务 |
| 3PC | 强一致 | 略优于2PC | 低 | 对2PC的改进场景 |
| TCC | 最终一致 | 高 | 高 | 对性能和一致性都有要求的业务 |
| Saga | 最终一致 | 高 | 中 | 长事务、微服务编排 |
| 本地消息表 | 最终一致 | 高 | 中 | 异步解耦场景 |
| 事务消息 | 最终一致 | 高 | 低 | 依赖 MQ 的异步场景 |
| 最大努力通知 | 最终一致 | 高 | 低 | 通知类、对一致性要求低的场景 |
实际项目中，通常会根据一致性要求、性能要求、业务复杂度等因素综合选择合适的方案，甚至组合使用多种方案。