分布式事务

分布式事务是指跨越多个独立系统或数据库的事务操作，要求这些操作要么全部成功，要么全部失败，保证数据一致性。

为什么需要分布式事务

• 微服务、分库分表、异构系统等场景下，单体事务无法满足一致性需求。
• 例如：订单服务和库存服务分别在不同数据库，需保证下单和扣库存要么都成功，要么都失败。

分布式事务的挑战

• 网络不可靠、节点故障、时延等导致一致性难以保障。
• CAP理论：一致性（C）、可用性（A）、分区容错性（P）三者不可兼得。

常见分布式事务方案

1. 两阶段提交（2PC）

• 原理：协调者先让所有参与者准备（预提交），全部准备好后再统一提交。
• 优点：实现简单，强一致性。
• 缺点：阻塞、单点故障，性能较低。

2. 三阶段提交（3PC）

• 原理：在2PC基础上增加“预提交”阶段，降低阻塞风险。
• 优缺点：进一步提升容错，但实现复杂，实际应用较少。

3. 本地消息表/可靠消息最终一致性

• 原理：业务操作和消息发送在同一本地事务中，消息异步投递，保证最终一致性。
• 应用：如 RocketMQ 事务消息、阿里分布式事务解决方案。

4. TCC（Try-Confirm-Cancel）

• 原理：将业务操作拆分为 Try（预留资源）、Confirm（确认提交）、Cancel（回滚）三个阶段。
• 优点：灵活，适合强业务隔离场景。
• 缺点：实现复杂，需幂等、空回滚等保障。

5. SAGA

• 原理：将长事务拆分为一系列本地子事务，每步失败则按补偿逻辑回滚。
• 优点：高可用，适合长流程。
• 缺点：只保证最终一致性，补偿逻辑复杂。

典型应用场景

• 电商下单（订单、库存、支付等服务协同）
• 金融转账（多账户、多系统一致性）
• 微服务架构下的跨服务数据一致性

总结

• 分布式事务方案需结合业务场景权衡一致性、可用性与性能。
• 实际开发中，推荐优先采用本地消息表、SAGA等最终一致性方案，核心链路可用TCC或2PC。

---

参考：

• 分布式事务原理与实现