2PC和3PC协议

分手后的思念是犯贱 2023-06-06 04:53 14阅读 0赞

# 2PC和3PC协议 #

--------------------

## 目录 ##

1.  2PC
2.  3PC

--------------------

在分布式系统中，每个机器节点虽然能够明确知道自己在进行事务操作过程中的结果是成功或失败，但却无法直接获取其他分布式节点的操作结果。因此，当一个事务操作需要跨越多个分布式节点的时候，为了保持事务处理的ACID特性，就需要引入一个称为“**协调者（Coordinator）**”的组件来统一调度所有分布式节点的执行逻辑，这些被调度的分布式节点则被称为“**参与者（Participant）**”。协调者负责调度参与者的行为，并最终决定这些参与者是否要把事务真正进行提交。基于这个思想，衍生出了二阶段提交和三阶段提交两种协议。

--------------------

### 1. 2PC ###

2PC，是 Two-Phase Commit 的缩写，即二阶段提交。是计算机网络尤其是在数据库领域内，为了使基于分布式系统架构下的所有节点在进行事务处理过程中能保持原子性和一致性而设计的一种算法。二阶段提交也被认为是一种一致性协议，用来保证分布式数据的一致性。

##### 协议说明 #####

二阶段提交协议将事务的提交过程分成了两个阶段来进行处理，其执行流程如下。

--------------------

###### 阶段一：提交事务请求 ######

1.  事务询问  
    协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
2.  执行事务  
    各参与者节点执行事务操作，并将 Undo 和 Redo 信息记入事务日志中。
3.  各参与者向协调者反馈事务询问的响应  
    如果参与者成功执行了事务操作，那么就反馈给协调者 Yes 响应，表示事务可以执行；如果参与者没有成功执行事务，那么就反馈给协调者 No 响应，表示事务不可以执行。

上述内容近似协调者组织各参与者对一次事务操作的投票表态过程，因此二阶段提交协议的阶段一也被称为“投票阶段”，即各参与者投票表明是否要继续执行接下来的事务提交操作。

--------------------

###### 阶段二：执行事务提交 ######

在阶段二中协调者会根据各参与者的反馈情况来决定最终是否可以进行事务提交操作，在正常情况下，包含以下两种可能。

**执行事务提交**  
假设协调者从所有的参与者获取的反馈都是 Yes 响应，那么就会执行事务提交。

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

**中断事务**  
假设任何一个参与者向协调者反馈 No 响应，或者在等待超时之后，协调者尚无法接受到所有参与者的反馈响应，那么就会中断事务。

1.  发送回滚请求。  
    协调者向所有的参与者发送 Rollback 请求。
2.  事务回滚  
    参与者接受到 Rollback 请求后，会利用其在阶段一中记录的 Undo 信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源。
3.  反馈事务回滚结果  
    参与者在完成事务回滚之后，向协调者发送 Ack 消息。
4.  中断事务  
    协调者接受到所有参与者反馈的 Ack 消息后，完成事务中断。

以上就是二阶段提交的过程中，前后两个阶段分别进行的处理逻辑。简单来讲，二阶段提交将一个事务的处理过程分为了投票和执行两个阶段，其核心是对每个事务都采用先尝试提交的处理方式，因此也可以将二阶段提交看做一个强一致性的算法。

下图展示了二阶段提交过程中“事务提交”和“事务中断”两种场景下的交互流程。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70 1]

--------------------

###### 优缺点 ######

二阶段提交协议的优点：原理简单，实现方便。

二阶段提交协议的缺点：同步阻塞，单点问题，脑裂，太过保守。

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

--------------------

### 2. 3PC ###

了解二阶段提交协议的设计和实现原理，并明确指出了其在实际运行过程中可能存在诸多问题，比如同步阻塞、协调者的单点问题、脑裂和太过保守的容错机制等缺陷，因此研究者在二阶段提交协议的基础上进行了改进，提出了三阶段提交协议。

#### 协议说明 ####

3PC，是 Three-Phase Commit 的缩写，即三阶段提交，是 2PC 的改进版，其将二阶段提交协议的“提交事务请求”过程一分为二，形成了 canCommit，preCommit 和 doCommit三个阶段组成的事务处理协议，协议设计图如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70 2]

--------------------

###### 阶段一：canCommit ######

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

--------------------

###### 阶段二：preCommit ######

在阶段二，协调者会根据各参与者的反馈情况来决定是否进行事务的 PreCommit 操作，正常情况下，包含两种可能。

**执行事务预提交**  
假如协调者从所有的参与者获得的反馈都是 Yes，那么就会执行事务预提交。

1.  发送预提交请求  
    协调者向所有参与者节点发出 preCommit 请求，并进入 Prepared 阶段。
2.  事务预提交  
    参与者接收到 preCommit 请求后，会执行事务操作，并将 Undo 和 Redo 信息记录到事务日志中。
3.  各参与者向协调者反馈事务执行的响应  
    如果参与者成功执行了事务操作，那么就会反馈给协调者 Ack 响应，同时等待最终的指令：提交（commit）或中止（abort）。

**中断事务**  
假如任何一个参与者向协调者反馈了 No 响应，或者在等待超时之后，协调者尚无法接受到所有参与者的反馈响应，那么就会中断事务。

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

--------------------

###### 阶段三：doCommit ######

该阶段将进行真正的事务提交，会存在以下两种可能的情况。

**执行提交**

1.  发送提交请求  
    进入这一阶段，假设协调者处于正常工作状态，并且它接收到了来自所有参与者的 Ack 响应，那么它将从“预提交”状态转换到“提交”状态，并向所有的参与者发送 doCommit 请求。
2.  事务提交  
    参与者接收到 doCommit 请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源。
3.  反馈事务提交结果  
    参与者在完成事务提交之后，向协调者发送 Ack 消息。
4.  完成事务  
    协调者接收到所有参与者反馈的 Ack 消息后，完成事务。

**中断事务**  
进入这一阶段，假设协调者处于正常工作状态，并且有任意一个参与者向协调者反馈了 No 响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，那么就会中断事务。

1.  发送中断请求  
    协调者向所有的参与者节点发送 abort 请求。
2.  事务回滚  
    参与者接收到 abort 请求后，会利用其在阶段二中记录的 Undo 信息来执行回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源。
3.  反馈回滚结果  
    参与者在完成事务回滚之后，向协调者发送 Ack 消息。
4.  中断事务  
    协调者接收到所有参与者反馈的 Ack 消息后，中断事务。

需要注意的是，一旦进入阶段三，可能会存在以下两种故障。

*  协调者出现问题。
 *  协调者和参与者之间的网络出现故障。

无论哪种情况，最终都会导致参与者无法及时接收来自协调者的 doCommit 或是 abort 请求，针对这样的异常情况，参与者都会在等待超时之后，继续进行事务提交。

--------------------

###### 优缺点 ######

三阶段提交协议的优点：相较于二阶段提交协议，三阶段提交协议最大的优点就是降低了参与者的阻塞范围，并且能够在出现单点故障后继续达成一致。

三阶段提交协议的缺点：三阶段提交协议在去除阻塞的同时也引入了新的问题，那就是在参与者接收到 preCommit 消息后，如果网络出现分区，此时协调者所在的节点和参与者无法进行正常网络通信，在这种情况下，该参与者依然会进行事务的提交，这必然会出现数据的不一致。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70]: /images/20230601/8539bff3978c40028e7b3012e89e74ff.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70 1]: /images/20230601/2f79c02713f04a2db075236ac8979a6c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70 2]: /images/20230601/1c95c7ef68434927a35cd5743ad41eec.png