【分布式事务】两阶段提交和三阶段提交的区别

前言

1.分布式理论：一致性协议：2PC

1.1 什么是2PC

2PC,即两阶段提交协议的简写，是整个事务过程分为两个阶段，准备阶段（Prepare phase）和提交阶段（Commit phase）

1.2. 两个阶段过程：

1. 准备阶段：事务管理器给每个参与者发送Prepare消息，每个数据库参与者在本地执行事务，并写本地的Undo/Redo日志,此时事务没有提交。
   Undo日志是记录修改前的数据，用户数据库回滚.
   Redo日志是记录修改后的数据，用于提交事务后写入数据文件

2. 提交阶段：如果事务管理器接收到了参与者的执行失败或者超时消息时，直接给每个参与者发送回滚（RollBack）消息，否则，发送提交（Commit）消息;
   参与者根据事务管理器的指令执行提交或者回滚操作。并且释放事务处理中所需的锁资源。
   注意：必须在最后阶段才释放锁资源

1.4. 2PC执行流程

成功执行事务事务提交流程 ，如下

• 阶段一:

1. 事务询问：协调者向所有参与者发送事务内容，询问是否可以执行事务提交操作。
   并开始等待各参与者的响应

2. 执行事务（写本地的Undo/Redo日志）

3. 各参与者向协调者反馈事务询问的响应

   总结：各个参与者进行投票是否让事务进行

Tip:什么是Ack
Ack确认字符,在数据通信中，接收站发给发送站的一种传输类控制字符。 表示发来的数据已确认接收无误

• 阶段二:

1. 发送提交请求:
   协调者向所有参与者发出Commit请求
2. 事务提交
   参与者收到Commit请求后,会正式执行事务提交操作，并在完成提交之后释放整个事务执行期间占用的事务资源
3. 反馈事务提交结果
   参与者在完成事务提交之后，向协调者发送Ack信息
4. 完成事务
   协调者接收到所有参与者反馈的Ack信息后，完成事务

1.5. 2PC的优点和缺点:

1.优点：原理简单，实现简单
2.缺点：同步阻塞，单点问题，数据不一样，过于保守

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

2.什么是3PC

3PC是2PC的改进版，将2PC的"提交事务请求"过程一分为二，共形成了由CanCommit,PreCommit和doCommit三个阶段组成的事务处理协议

2.1. 阶段一：CanCommit

1. 事务询问
   协调者向所有的参与者发送一个包含事务内容的canCommit请求，询问是否可以执行事务操作，并开始等待各参与者的响应

2. 各参与者向协调者反馈事务询问的响应
   参与在接收在接收来自协调者的包含了事务内容的canCommit请求后。
   正常情况下，如果自身认为可以顺利执行事务，则反馈Yes响应，并进入预备状态，否则反馈NO响应

2.2. 阶段二：PreCommit

协调者得到所有事务参与者的响应结果，根据结果的,协调者会出现两种执行情况。执行事务预提交。
或者中间事务，如果接受到都是Yes就执行事务。

1. 执行事务预提交分为3个步骤
   - 发送预提交请求：
   协调者向所有参与者节点发出preCommit请求，并进入prepared阶段

   • 事务预提交
     参与者接受到preCommit请求后，会执行事务操作，并将Undo和Redo信息记录到事务日志中

     • 各参与者向协调者反馈事务执行的结果：
       若参与者成功执行了事务操作，那么反馈Ack

   若任一参与者反馈了No相应，或者在等待超时后，协调者还无法接收所有参与者反馈，则中断事务

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

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

2.3. 阶段三：do commit

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

1. 执行事务提交

   • 发送提交请求
     如果协调者处于正常工作状态，并且它接收到了来自所有参与者的Ack响应，那么他将从预提交状态转换为提交状态，并向所有的参与者发送doCommit请求

   • 事务提交
     参与者接收到doCommit请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行过程中占用的事务资源

   • 反馈事务提交结果
     参与者在完成事务提交后，向协调者发送Ack响应

   • 完成事务：协调者接收到所有参与者反馈的Ack消息后，完成事务

2. 中断事务

   • 发送中断请求：协调者向所有的参与者节点发送abort请求
   • 事务回滚：参与者收到abort请求后，会根据记录的Undo信息来执行事务回滚。并在完成回滚之后释放整个事务执行期间占用的资源
   • 反馈事务回滚结果：参与者在完成事务回滚后，向协调者发送Ack消息
   • 中断事务：协调者接收到所有参与者反馈的Ack消息后，中断事务

注意：一旦进入阶段三，可能会出现 2 种故障

1. 协调者出现问题
2. 协调者和参与者之间的网络故障

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

2.4. 3PC的优点和缺点：

优点：

1. 首先对于协调者和参与者都设置了超时机制（在2PC中，只有协调者拥有超时机制，即如果在一定时间内没有收到参与者的消息则默认失败）,主要是避免了参与者在长时间无法与协调者节点通讯（协调者挂掉了）的情况下，无法释放资源的问题，因为参与者自身拥有超时机制会在超时后，自动进行本地commit从而进行释放资源。而这种机制也侧面降低了整个事务的阻塞时间和范围。

2. 通过CanCommit、PreCommit、DoCommit三个阶段的设计，
   相较于2PC而言，多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的

3. PreCommit是一个缓冲，保证了在最后提交阶段之前各参与节点的状态是一致的