2PC、3PC

二阶段提交协议（2PC）、三阶段提交协议（3PC）都是为了解决分布式一致性问题。

  在分布式系统中为了保证事务处理的ACID特性，引入了协调者组件来同一调度所有分布式节点的执行逻辑，被调度的分布式节点称为参与者，协调者负责调度参与者的行为，并决定这些参与者是否提交事务。
  

2PC

二阶段提交协议将事务的提交过程分成两个阶段来处理：

第一个阶段是提交事务请求：

• 首先协调者向所有参与者发送事务内容，询问是否可以执行事务提交操作，并等待参与者的响应。
• 参与者执行事务操作，并将 undo 和 redo 信息记入事务日志中。
• 如果参与者成功执行了事务操作，就反馈给协调者 yes 响应，表示事务可以执行，否则反馈 no 响应，表示事务不可以执行。

第二个阶段是执行事务提交：

• 协调者根据参与者的反馈情况来决定是否进行事务提交操作， 如果所有参与者反馈的都是 yes 响应，就会执行事务提交：

  • 首先协调者向所有参与者发出 commit 请求。
  • 参与者收到 commit 请求后，执行事务提交操作。
  • 参与者完成事务提交后，释放事务执行期间占用的资源，并向协调者发送 ack 消息。
  • 协调者收到所有参与者反馈的 ack 消息后，完成事务提交。

• 如果有一个参与者反馈的是 no 响应，或者等待超时后，协调者依然没有接收到所有参与者的响应，就会中断事务：

  • 协调者向所有参与者发出回滚请求。
  • 参与者收到回滚请求后，利用第一阶段中记录的 undo 信息来执行事务回滚操作。
  • 参与者完成事务回滚后，释放事务执行期间占用的资源，并向协调者发送 ack 消息。
  • 协调者收到所有参与者反馈的 ack 消息后，完成事务中断。

优点：原理简单，实现方便。

缺点：

1. 同步阻塞：所有参与者在等待其它参与者响应时都处于同步阻塞状态，无法进行其它操作。
2. 单点问题：协调者在 2PC 中起到了非常大的作用，发生故障将会造成很大的影响。尤其是在提交阶段，如果发生故障，所有参与者会一直同步阻塞，无法进行其它操作。
3. 数据不一致：在提交阶段，如果发生局部网络异常，或协调者在还没有发送完 commit 请求前自身崩溃了，会导致只有部分参与者收到了 Commit 请求，也就是说只有部分参与者提交了事务，使得分布式系统出现数据不一致的现象。
4. 太过保守：没有完善的容错机制，任意一个节点失败都会导致整个事务失败。

3PC

3PC 是 2PC 的改进版，它将 2PC 的提交事务请求过程分为

第一个阶段是 CanCommit：

• 协调者向所有参与者发送包含事务内容的 canCommit 请求，询问是否可以执行事务提交操作，并等待参与者的响应。
• 参与者收到请求后，如果认为自己可以执行事务，就反馈 yes 响应，进入预备状态，否则反馈 no 响应。

第二个阶段是 PreCommit：

• 协调者根据参与者的反馈情况来决定是否进行事务的 PreCommit 操作，如果所有参与者反馈的都是 yes 响应，就会执行事务预提交：

  • 协调者向所有参与者发出 PreCommit 请求，并进入准备阶段。
  • 参与者收到 PreCommit 请求后，会执行事务操作，并将 undo 和 redo 信息记录到事务日志中。
  • 参与者完成事务操作后，向协调者发送 ack 消息，并等待最终的指令：提交或中断。

• 如果有一个参与者反馈的是 no 响应，或者等待超时后，协调者依然没有接收到所有参与者的响应，就会中断事务：

  • 协调者向所有参与者发出中断请求。
  • 参与者收到中止请求或者超时后，都会中断事务。

第三个阶段是 doCommit：

• 该阶段进行真正的事务提交，存在两种情况，第一种情况是执行提交：

  • 也就是协调者收到了所有参与者的 ack 响应，它从预提交状态转换为提交状态，并向所有参与者发送 doCommit 请求。
  • 参与者收到 doCommit 请求后，正式执行事务提交操作。
  • 参与者完成事务提交后，释放事务执行期间占用的资源，并向协调者发送 ack 消息。
  • 协调者收到所有参与者反馈的 ack 消息后，完成事务。

• 第二种情况是中断事务，也就是如果有一个参与者反馈的是 no 响应，或者等待超时后协调者依然没有接收到所有参与者的响应，就会中断事务：

  • 协调者向所有参与者发送中断请求。
  • 参与者收到中断请求后，利用第二阶段中记录的 undo 信息来执行事务回滚操作。
  • 参与者完成事务回滚后，释放事务执行期间占用的资源，并向协调者发送 ack 消息。
  • 协调者收到所有参与者反馈的 ack 消息后，完成事务中断。

优点：和 2PC 相比，3PC 最大的优点是降低了参与者的阻塞范围，并且能够在出现单点故障后继续达成一致。

缺点：在参与者收到 PreCommit 消息后，如果网络出现分区，协调者和参与者无法正常通信，而参与者依然会进行事务的提交，这会导致数据不一致。