分布式事务｜ 2PC与3PC 详解

最新推荐文章于 2024-04-19 22:41:15 发布

小生凡一

最新推荐文章于 2024-04-19 22:41:15 发布

阅读量756

点赞数 3

分类专栏：遇见Golang，拥抱未来文章标签：分布式数据库

本文链接：https://blog.csdn.net/weixin_45304503/article/details/135052892

版权

遇见Golang，拥抱未来专栏收录该内容

39 篇文章 45 订阅

订阅专栏

分布式事务

2PC

2PC ，两阶段提交，将事务的提交过程分成资源准备和资源提交两个阶段，并且由事务协调者来协调所有事务参与者，如果准备阶段所有事务参与者都预留资源成功，则进行第二阶段的资源提交，否则事务协调者回滚资源。

1. 第一阶段：准备阶段

由事务协调者询问通知各个事务参与者，是否准备好了执行事务，具体流程图如下：

协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待答复。
各参与者执行本地事务操作，将undo和redo信息记入事务日志中(但不提交事务)。
如参与者执行成功，给协调者反馈同意，否则反馈中止，表示事务不可以执行。

2. 第二阶段：提交阶段

协调者收到各个参与者的准备消息后，根据反馈情况通知各个参与者commit提交或者rockback回滚。

2.1 事务提交：

当第一阶段所有参与者都反馈同意时，协调者发起正式提交事务的请求，当所有参与者都回复同意时，则意味着完成事务，具体流程如下：

协调者节点向所有参与者节点发出正式提交的commit请求。
收到协调者的commit请求后，参与者正式执行事务提交操作，并释放在整个事务期间内占用的资源。
参与者完成事务提交后，向协调者节点发送ACK消息。
协调者节点收到所有参与者节点反馈的ACK消息后，完成事务。

2.2 事务回滚

如果任意一个参与者节点在第一阶段返回的消息为中止，或者协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时，那么这个事务将会回滚，具体流程如下：

3. 2PC 缺点

二阶段提交确实能够提供原子性的操作，但二阶段提交还是有几个缺点：

性能问题：执行过程中，所有参与节点都是事务阻塞性的，当参与者占用公共资源时，其他第三方节点访问公共资源就不得不处于阻塞状态，为了数据一致性而牺牲了可用性，对性能影响比较大，不适合高并发高性能场景。
可靠性问题：2PC非常依赖协调者，当协调者发生故障时，尤其是第二阶段，那么所有参与者就会处于锁定事务资源的状态中，导致无法继续完成事务操作。如果是协调者挂掉了，可以重新选举一个协调者，但是无法解决因为协调者当即导致的参与者处于阻塞状态的问题。
数据一致性：当二阶段中的协调者向参与者发起了commit请求操作之后，发生了局部网络异常或者在发送commit请求过程中，协调者发生了故障，这会导致只有一部分参与者接受到了commit请求。 而在这部分参与者接受到commit请求之后就会执行commit操作。但是其他部分内接到commit请求的机器则无法执行事务操作。于是整个分布式系统中，就会出现数据不一致的问题。
二阶段无法解决的问题：协调者在发出commit消息之后宕机，而唯一接受到这条消息的参与者同时也宕机了，那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没有人知道这个事务是否已经提交。

其实2PC的问题是可以规避的，那就是通过log的日志进行记录，一切的事务提交与否以log记录为主。

3PC

3PC，三阶段提交协议，是二阶段协议的改进版本，三阶段提交有两个改动点：

在协调者和参与者中都引入超时机制
在第一阶段和第二阶段中插入一个准备阶段，保证了在最后提交阶段之前各个参与节点的状态是一致的

所以3PC会分3个阶段，CanCommit准备阶段，PreCommit预提交阶段，DoCommit提交阶段，处理流程如下：

1. 阶段一：CanCommit 准备阶段

协调者向参与者发送canCommit请求，参与者如果可以提交就返回Yes响应，否则返回No响应，具体流程如下：

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

2. 阶段二：PreCommit阶段

协调者根据参与者的反应情况来决定是否可以进行事务的preCommit操作。根据响应情况，有以下两种可能：

2.1 执行事务：

假如所有参与者均反馈yes，协调者预执行事务，具体如下：

发送预提交请求：协调者向参与者发送preCommit请求，并进入准备阶段。
事务预提交：参与者接受到preCommit请求后，会执行本地事务操作，并将undo和redo信息记录到事务日志中，但并不提交事务。
响应反馈：如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。

2.2 中断事务：

假如有任何一个参与者向协调者发送No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断，流程如下：

发送中断请求：协调者向所有参与者发送abort请求
中断事务：参与者收到来自协调者的abort请求之后(或者超时之后，仍为收到协调者的请求)，执行事务的中断。

3. 阶段三：doCommit阶段

该阶段进行真正的事务提交，也可以分为以下两种情况：

3.1 提交事务：

发送提交请求：协调接受到所有参与者发送的ACK响应，那么他将从预提交状态进入到提交状态，并向所有参与者发送doCommit请求
本地事务提交：参与者接受到doCommit请求之后，执行正式的事务提交，并在完成事务提交之后释放所有事务资源
响应反馈：事务提交完之后，向协调者发送ack响应
完成事务：协调者接受到所有参与者的ack响应之后，完成事务。

3.2 中断事务：

任何一个参与者反馈no，或者等待超时后，协调者无法收到所有参与者的反馈，即中断业务

发送中断请求：如果协调者处于工作状态，向所有参与者发出abort请求
事务回滚：参与者接受到abort请求之后，利用其在二阶段记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。
反馈结果：参与者完成事务回滚之后，向协调者反馈ACK消息
中断事务：协调者接收参与者反馈的ACK消息之后，执行事务的中断

进入doCommit阶段后，无论协调者出现问题，或者协调者与参与者之间的网络出现问题，都会导致参与者无法接受到协调者发出的doCommit请求或者abort请求。此时，参与者都会在等待超时之后，继续执行事务提交。这其实给予改了来决定，当进入第三阶段时，说明第一阶段收到所有参与者的canCommit的响应都是Yes，所以一句话概括就是，当进入第三阶段时，由于网络超时等原因，虽然参与者没有收到commit或者abort，但是他有理由相信：成功提交的几率很大，比较前面收到所有的canCommit的Yes。