不是吧不是吧，现在还有人不知道2PC和3PC么

最新推荐文章于 2024-03-23 10:46:03 发布

Java秦心

最新推荐文章于 2024-03-23 10:46:03 发布

阅读量108

点赞数

文章标签：分布式数据库 java 多线程区块链

原文链接：https://juejin.cn/post/6920062407435878408

版权

说到一致性协议，就离不开分布式。以前的单机情况下，我们用数据库的事务保证一致性，原子性，隔离性，持久性，简称ACID。分布式情况下，就不能用这个保证一致性了，所以，分布式场景中，也对应有分布式事务，这里就说一下一致性协议

一致性协议2PC

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

2PC本质是XA规范标准实现，属于CP

在计算机中部分关系数据库如Oracle，MySQL支持两阶段提交协议两个阶段过程：

准备阶段：事务管理器给每个参与者发送Prepare消息，每个数据库参与者在本地执行事务，并写本地的Undo/Redo日志，此时事务没有提交。（Undo日志是记录修改前的数据，用于数据库回滚，Redo日志是记录修改后的数据，用于提交事务后写入数据文件）
提交阶段：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个阶段参与者发送回滚（Rollback）消息；否则，发送提交（Commit）消息；参与者根据事务管理器的执行执行提交或者回滚操作，并释放事务处理中使用的锁资源。注意：必须在最后阶段释放锁资源

协议说明：顾名思义，二阶段提交就是将事务的提交过程分成了两个阶段来进行处理。流程如下：

成功执行事务提交流程

阶段一：

事务询问：协调者向所有的参与者发送事务内容，询问是否可以执行事务操作流程，并开始等待各参与者的响应
执行事务（写本地的Undo/Redo日志）
各参与者向协调者反馈事务询问的响应

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

什么是ACK？

ACK 确认字符，在数据通信中，接收站发给发送站的一种传输类控制字符。表示发来的数据已确认接收无误
复制代码

阶段二：

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

事务中断提交流程

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

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

阶段二：

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

从上面的逻辑可以看出，二阶段提交就做了2个事情：投票，执行

案例：组织爬山（我，旭哥，leader）

第一阶段（准备阶段）：
- 我（TM）作为组织者，串行跟旭哥，leader获取是否到达山脚的结果
- 旭哥检查了一下自己的登山设备，然后去山脚等待。这时候进入了阻塞等待
- leader重复了上述操作
旭哥，leader超时或者拒绝（这时候旭哥发现，自己的袜子忘记带了！），我就记录为拒绝
第二阶段（提交阶段）：
- 我将是否能上山串行告诉旭哥和leader
问题：
- 阻塞：成员阻塞浪费资源
- 死锁：TM故障，引起的事务不提交
- 脑裂：部分参与者提交事务（参与者A提交后，TM和参与A同时死亡，参与B事务不确定（没收到Commit）从数据库层面来说，首先第一阶段做SQL执行，接下来需要记录事务日志（Redo，Undo日志），第二阶段我们要做SQL的提交

一致性协议3PC

什么是三阶段提交

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

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

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

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

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

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

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

阶段三：doCommit

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

执行事务提交

发送提交请求：进入这一阶段，假设协调者处于正常工作的状态，并且它接收到了来自所有参与者的Ack响应，那么他将从预提交状态转化为提交状态，并向所有的参与者发送doCommit请求。

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

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

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

中断事务

发送中断请求：协调者向所有的参与者节点发送abort请求。

事务回滚：参与者收到abort请求后，会根据记录的Undo信息来执行事务回滚，并在完成回滚之后释放整个事务执行期间占用的资源

反馈事务回滚结果：参与者在完成事务回滚后，向协调者发送Ack消息

中断消息：协调者接收到所有参与者反馈的Ack消息之后，中断事务

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

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

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

案例：爬山

第一阶段（准备阶段）：
- 我（TM）作为组织者，串行跟leader，旭哥获取是否到达山脚的结果。
- leader看了自己的时间表，也检查了登山设备（水，登山鞋），然后去山脚等待。这时进入阻塞等待。
- 旭哥重复上述过程。
- 旭哥，leader超时或者拒绝，我将之记录为拒绝
第二阶段（对齐阶段）：
- 我在山脚进行人员点名并预约上山，然后各自热身。
第三阶段（提交阶段）：
- 我通知上山
- 分支：旭哥点名后忙着跟小姐姐聊天，然后没接到上山通知，在约定时间到后自行上山

2PC对比3PC

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

问题:3PC协议并没有完全解决数据不一致问题。

作者：Five在努力
链接：https://juejin.cn/post/6920062407435878408