3PC（Three-Phase Commit，三阶段提交）

3pc是对两阶段提交（2PC）的改良版，试图解决前任的同步阻塞问题和单点故障死锁问题。

3pc做了两点核心改进：

1. 拆分阶段 —— 将2PC的准备阶段一分为二，变成了 CanCommit、PreCommit 和 DoCommit 三个阶段。
2. 引入超时机制 —— 同时在协调者和参与者端都引入了超时机制（2PC只有协调者有超时机制）。

执行流程：

• 第一阶段：CanCommit（询问阶段）

  1. 协调者向参与者发送 CanCommit 请求，询问是否可以执行事务。

  ⚠️注意：（核心改良点，“缓解”同步阻塞问题） 此时参与者不锁定资源，只是纯粹基于自身状态（如网络、负载）评估是否能做。能做就回 Yes，不能就回 No。这大大减少了无效的资源锁定。

• 第二阶段：PreCommit（预提交阶段）

  1. 如果所有节点回 Yes，协调者向参与者发送 PreCommit 请求。
  2. 执行与锁定：参与者收到后，开始执行事务操作，记录 Undo/Redo 日志，并锁定资源（等同于 2PC 的第一阶段）。然后回复 Ack。

  ⚠️注意： 如果在该阶段协调者超时未收到反馈，或者有节点回 No，则触发回滚。

• 第三阶段：DoCommit（正式提交阶段）

  1. 协调者收到所有 PreCommit 的 Ack 后，发送 DoCommit 请求。
  2. 参与者正式提交事务，释放资源，并回复 Ack 完成。

  ⚠️注意：（核心改良点，“打破”单点故障死锁问题） 如果进入了第三阶段，由于网络原因参与者没有收到协调者发来的 DoCommit 信号，在超时后，参与者会自动触发“自动提交（Auto-Commit）”。 （因为经过阶段二后达成共识“所有节点准备提交”，所以这里倾向于提交而非回滚）

致命缺点：

1. 数据不一致问题（Data Inconsistency） —— 依然无法避免数据不一致的情况，比如第二阶段协调者发出回滚指令后由于网络分区导致某些参与者收不到回滚指令而提交数据。