2PC

2PC （ Two-Phase Commit缩写）即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Preparephase）、提交阶段（commit phase），2是指两个阶段，P是指准备阶段，C是指提交阶段。

准备阶段

  1. 事务询问 协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
  2. 执行事务 (写本地的Undo/Redo日志)

  3. 各参与者向协调者反馈事务询问的响应 总结: 各个参与者进行投票是否让事务进行.

    提交阶段

  4. 发送回滚请求： 协调者向所有参与者发出 Rollback 请求。

  5. 事务回滚： 参与者接收到 Rollback 请求后，会利用其在阶段一中记录的 Undo 信息来执行事务回滚操作，并在完成回滚之后 释放在整个事务执行期间占用的资源。
  6. 反馈事务回滚结果： 参与者在完成事务回滚之后，向协调者发送 Ack 信息。
  7. 中断事务： 协调者接收到所有参与者反馈的 Ack 信息后，完成事务中断。 从上面的逻辑可以看出，二阶段提交就做了2个事情：投票，执行。

    2PC 优点缺点

    优点

    原理简单，实现方便

    缺点

    同步阻塞
    二阶段提交协议存在最明显也是最大的一个问题就是同步阻塞，在二阶段提交的执行过程中，所有参与该事务操作的逻辑都处于阻塞状态，也就是说，各个参与者在等待其他参与者响应的过程中，无法进行其他操作。这种同步阻塞极大的限制了分布式系统的性能。
    单点问题
    协调者在整个二阶段提交过程中很重要，如果协调者在提交阶段出现问题，那么整个流程将无法运转，更重要的是：其他参与者将会处于一直锁定事务资源的状态中，而无法继续完成事务操作。
    数据不一致
    假设当协调者向所有的参与者发送 commit 请求之后，发生了局部网络异常或者是协调者在尚未发送完所有commit 请求之前自身发生了崩溃，导致最终只有部分参与者收到了 commit 请求。这将导致严重的数据不一致问题。
    过于保守
    如果在二阶段提交的提交询问阶段中，参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话，这时协调者只能依靠其自身的超时机制来判断是否需要中断事务，显然，这种策略过于保守。换句话说，二阶段提交协议没有设计较为完善的容错机制，任意一个节点失败都会导致整个事务的失败。

    3PC

    3PC，全称 “three phase commit”，是 2PC 的改进版，将 2PC 的 “提交事务请求” 过程一分为二，共形成了由CanCommit、PreCommit和doCommit三个阶段组成的事务处理协议。
    image.png

    阶段一：CanCommit

    ① 事务询问
    协调者向所有的参与者发送一个包含事务内容的canCommit请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
    ② 各参与者向协调者反馈事务询问的响应参与者在接收到来自协调者的包含了事务内容的canCommit请求后，正常情况下，如果自身认为可以顺利执行事务，则反馈Yes响应，并进入预备状态，否则反馈No响应。

    阶段二：PreCommit

    协调者在得到所有参与者的响应之后，会根据结果有2种执行操作的情况：执行事务预提交，或者中断事务假如所有参与反馈的都是Yes，那么就会执行事务预提交。

    1. 执行事务预提交分为 3 个步骤

    ① 发送预提交请求：协调者向所有参与者节点发出preCommit请求，并进入prepared阶段
    ② 事务预提交：参与者接收到preCommit请求后，会执行事务操作，并将Undo和Redo信息记录到事务日志中。
    ③ 各参与者向协调者反馈事务执行的结果：若参与者成功执行了事务操作，那么反馈Ack
    若任一参与者反馈了No响应，或者在等待超时后，协调者尚无法接收到所有参与者反馈，则中断事务

    2. 中断事务也分为2个步骤：

    ① 发送中断请求：
    协调者向所有参与者发出abort请求。
    ② 中断事务：
    无论是收到来自协调者的abort请求或者等待协调者请求过程中超时，参与者都会中断事务

    阶段三：do Commit

    该阶段做真正的事务提交或者完成事务回滚，所以就会出现两种情况：

    1. 执行事务提交

    ① 发送提交请求：
    进入这一阶段，假设协调者处于正常工作状态，并且它接收到了来自所有参与者的Ack响应，那么他将从预提交状态转化为提交状态，并向所有的参与者发送doCommit请求。
    ② 事务提交：
    参与者接收到doCommit请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行过程中占用的事务资源。
    ③ 反馈事务提交结果：参与者在完成事务提交后，向协调者发送Ack响应。
    ④ 完成事务：协调者接收到所有参与者反馈的Ack消息后，完成事务。

    2. 中断事务

    ① 发送中断请求：协调者向所有的参与者节点发送abort请求。
    ② 事务回滚：参与者收到abort请求后，会根据记录的Undo信息来执行事务回滚，并在完成回滚之后释放整个事务执行期间占用的资源。
    ③ 反馈事务回滚结果：参与者在完成事务回滚后，向协调者发送Ack消息。
    ④ 中断事务：协调者接收到所有参与者反馈的Ack消息后，中断事务。 :::warning 注意：一旦进入阶段三，可能会出现 2 种故障：
  • 协调者出现问题
  • 协调者和参与者之间的网络故障

如果出现了任一一种情况，最终都会导致参与者无法收到 doCommit 请求或者 abort 请求，针对这种情况，参与者都会在等待超时之后，继续进行事务提交 :::

对比

  • 在2PC中，只有协调者拥有超时机制，即如果在一定时间内没有收到参与者的消息则默认失败，而3PC对于协调者和参与者都设置了超时机制，主要是避免了参与者在长时间无法与协调者节点通讯（协调者挂掉了）的情况下，无法释放资源的问题，因为参与者自身拥有超时机制会在超时后，自动进行本地commit从而进行释放资源。而这种机制也侧面降低了整个事务的阻塞时间和范围。
  • 3PC通过CanCommit、PreCommit、DoCommit三个阶段的设计，相较于2PC而言，多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的 。
  • PreCommit是一个缓冲，保证了在最后提交阶段之前各参与节点的状态是一致的。 :::warning 问题：3PC协议并没有完全解决数据不一致问题。 :::