2PC（Two-Phase Commit，两阶段提交）

2PC将分布式事务的提交过程分为两个角色和两个阶段。

两个角色：

• 一个协调者（Coordinator） —— 判断事务是否提交/回滚
• 多个参与者（Participant） —— 提供业务处理、业务提交和业务回滚三个动作的实现

两个阶段：

• 准备阶段（Prepare/Voting）
  1. 询问：协调者向所有参与者发送事务内容，询问是否可以执行提交，并等待响应。
  2. 执行并锁定：参与者执行事务操作，将 Undo/Redo 日志计入系统，锁定资源，但不提交事务。
  3. 反馈：参与者如果执行成功，回复 Yes（同意）；如果失败（如遇到冲突或死锁），回复 No（拒绝）。
• 提交阶段（Commit/Rollback）
  • 情况 A：所有参与者均回复 Yes（成功提交）
    1. 发出提交：协调者向所有参与者发送 Commit 请求。
    2. 正式提交：参与者正式完成事务提交，释放第一阶段锁定的资源。
    3. 反馈并完成：参与者向协调者发送 Ack，协调者收到所有 Ack 后，事务完成。
  • 情况 B：有任何一个参与者回复 No 或超时未响应（回滚）
    1. 发出回滚：协调者向所有参与者发送 Rollback 请求。
    2. 利用日志回滚：参与者利用第一阶段的 Undo 日志回滚操作，释放资源。
    3. 反馈并取消：参与者发送 Ack，协调者完成事务中断。

致命缺点：

1. 同步阻塞问题（Performance Bottleneck） —— 在第一阶段拿到锁到第二阶段释放锁期间，所有参与者都处于阻塞状态，第三方无法访问这些被锁定的资源，高并发下性能极差。
2. 单点故障死锁问题（Single Point of Failure） —— 一旦协调者在第二阶段挂掉，正在等待 Commit 信号的参与者将陷入无尽的等待和阻塞，资源无法释放。
3. 数据不一致问题（Data Inconsistency） —— 在第二阶段，如果协调者发出了 Commit 信号，但由于网络分区（Network Partition），只有部分参与者收到了 Commit，而另一部分没收到，就会导致部分节点提交、部分节点未提交，数据产生严重的强一致性破坏。