浅谈分布式事务

分布式事务是指 涉及多个独立数据源（如数据库、消息队列、缓存等）的事务，确保这些操作要么全部成功，要么全部回滚，以保证数据一致性。由于分布式系统的特性（网络分区、故障等），传统的 本地事务（单数据库事务） 无法直接适用，因此需要特殊的分布式事务处理机制。

1、分布式事务的核心问题

分布式事务主要面临 CAP 原则 和 BASE 理论 之间的权衡：

• CAP 原则（Consistency 一致性、Availability 可用性、Partition Tolerance 分区容错性）
• BASE 理论（Basically Available 基本可用、Soft state 软状态、Eventual consistency 最终一致性）

由于分布式系统必须保证 分区容错性（P），所以必须在 一致性（C） 和 可用性（A） 之间做权衡

2. 解决方案

方案	适用场景	一致性	性能	适用业务
2PC	强一致性数据库事务	强	低	银行转账
3PC	解决 2PC 阻塞问题	强	低	关键金融交易
TCC	业务可拆分为 Try/Confirm/Cancel	强	高	库存、支付
SAGA	允许最终一致性	最终一致性	高	电商订单
本地消息表	事务 + MQ	最终一致性	高	微服务架构
MQ 事务消息	可靠消息传递	最终一致性	高	订单支付

1. 2PC（两阶段提交协议）

适用场景： 数据库之间事务一致性要求高
原理：

• 第一阶段（准备阶段，Prepare）：协调者询问所有参与者是否可以提交事务（锁定资源，但不提交）。
• 第二阶段（提交阶段，Commit）：如果所有参与者都返回“准备好提交”，协调者发送“提交”命令，否则发送“回滚”命令。

优点：
保证强一致性
事务失败可以回滚

缺点：
资源长时间锁定，影响性能
单点故障（协调者挂掉可能导致事务卡住）

2. 3PC（三阶段提交协议）

适用场景： 解决 2PC 可能导致的阻塞问题
原理：

• 第一阶段（CanCommit）： 询问是否可以提交（减少锁持有时间）。
• 第二阶段（PreCommit）： 参与者准备提交事务，但不正式提交。
• 第三阶段（DoCommit）： 参与者收到最终决定后执行提交或回滚。

优点：
解决 2PC 的阻塞问题
超时机制避免单点故障

缺点：
依然可能导致数据不一致（网络分区时，部分提交）
依赖协调者

3. TCC（Try-Confirm-Cancel）

适用场景： 适用于业务可以拆分成“预留资源+确认提交+取消回滚”三步的情况，例如支付、库存管理等。
原理：

1. Try：尝试执行操作，预留资源（如锁定库存、冻结金额）。
2. Confirm：真正执行提交。
3. Cancel：如果失败，回滚预留资源。

优点：
高性能（无需长时间锁定资源）
可灵活扩展

缺点：
业务入侵较大，需要手动实现 Try、Confirm、Cancel 逻辑
存在“悬挂”问题（Confirm 阶段调用失败但 Cancel 失败）

4. SAGA（补偿事务）

适用场景： 适用于长时间事务，例如订单处理、支付等。
原理： 事务被拆分为多个 本地事务，每个事务都有对应的 补偿操作（撤销已完成的步骤）。
例如：

1. 扣除账户余额 -> 失败？退款
2. 扣除库存 -> 失败？恢复库存
3. 生成订单 -> 失败？取消订单

优点：
异步处理，性能高
适合长事务场景（跨多个微服务）

缺点：
需要业务设计补偿逻辑
可能会有“脏数据”

5. 本地消息表（事务消息）

适用场景： 适用于消息队列 + 事务的场景（如订单系统和支付系统分离）。
原理：

• 先将事务和消息写入本地数据库（同一个事务中）。
• 定时任务扫描未成功发送的消息，确保最终一致性。

优点：
保证事务和消息发送一致性
适用于 MQ 场景

缺点：
需要额外的定时任务处理

6. MQ 事务消息（可靠消息+最终一致性）

适用场景： 适用于微服务之间的数据一致性，如 RocketMQ 事务消息。
原理：

1. 发送“预处理消息”，但不让消费者处理。
2. 执行业务事务（如扣款）。
3. 事务成功 -> 消费者消费消息；事务失败 -> 消息回滚。

优点：
适合大规模分布式系统
低耦合

缺点：
依赖 MQ，可能有消息丢失风险