分布式事务(1)---2PC和3PC原理

朱雀 2022-12-23 09:57 134阅读 0赞

# 分布式事务(1)---2PC和3PC原理 #

**分布式事物基本理论**:基本遵循CPA理论，采用柔性事物特征，软状态或者最终一致性特点保证分布式事物一致性问题。

**分布式事物常见解决方案**:

1.  2PC两段提交协议
2.  3PC三段提交协议(弥补两端提交协议缺点)
3.  TCC或者GTS(阿里)
4.  消息中间件最终一致性
5.  使用LCN解决分布式事物，理念“LCN并不生产事务,LCN只是本地事务的搬运工”。

## **一、两阶段提交（2PC）** ##

两阶段提交又称**2PC**,2PC是一个非常经典的`强一致、中心化的原子提交协议`。

这里所说的中心化是指协议中有两类节点：一个是中心化`协调者节点`（coordinator）和`N个参与者节点`（partcipant）。

`两个阶段`：第一阶段：**投票阶段** 和第二阶段：**提交/执行阶段**。

`举例` **订单服务A**，需要调用 **支付服务B** 去支付，支付成功则处理购物订单为待发货状态，否则就需要将购物订单处理为失败状态。

那么看2PC阶段是如何处理的

**1、第一阶段：投票阶段**

![c3c5e917447a583d83da4451c75c6eaa.png][]

第一阶段主要分为3步

1）`事务询问`

**协调者** 向所有的 **参与者** 发送**事务预处理请求**，称之为**Prepare**，并开始等待各 **参与者** 的响应。

2）`执行本地事务`

各个 **参与者** 节点执行本地事务操作,但在执行完成后并**不会真正提交数据库本地事务**，而是先向 **协调者** 报告说：“我这边可以处理了/我这边不能处理”。.

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

如果 **参与者** 成功执行了事务操作,那么就反馈给协调者 **Yes** 响应,表示事务可以执行,如果没有 **参与者** 成功执行事务,那么就反馈给协调者 **No** 响应,表示事务不可以执行。

第一阶段执行完后，会有两种可能。1、所有都返回Yes. 2、有一个或者多个返回No。

**2、第二阶段：提交/执行阶段（成功流程）**

`成功条件`：所有参与者都返回Yes。

![e3ade8abfb29ee74e94b6112b7f096e1.png][]

第二阶段主要分为两步

1)`所有的参与者反馈给协调者的信息都是Yes,那么就会执行事务提交`

**协调者** 向 **所有参与者** 节点发出Commit请求.

2)`事务提交`

**参与者** 收到Commit请求之后,就会正式执行本地事务Commit操作,并在完成提交之后释放整个事务执行期间占用的事务资源。

**3、第二阶段：提交/执行阶段（异常流程）**

`异常条件`：任何一个 **参与者** 向 **协调者** 反馈了 **No** 响应,或者等待超时之后,协调者尚未收到所有参与者的反馈响应。

![b67c41099678e7bda4a88a5cf82f777a.png][]

异常流程第二阶段也分为两步

1)`发送回滚请求`

**协调者** 向所有参与者节点发出 **RoollBack** 请求.

2)`事务回滚`

**参与者** 接收到RoollBack请求后,会回滚本地事务。

**4、2PC缺点**

通过上面的演示，很容易想到2pc所带来的缺陷

1）`性能问题`

无论是在第一阶段的过程中,还是在第二阶段,**所有的参与者资源和协调者资源都是被锁住的**,只有当所有节点准备完毕，事务 **协调者** 才会通知进行全局提交，

**参与者** 进行本地事务提交后才会释放资源。这样的**过程会比较漫长，对性能影响比较大**。

2）`单节点故障`

由于**协调者**的重要性，一旦 **协调者** 发生故障。**参与者** 会一直阻塞下去。尤其在第二阶段，**协调者** 发生故障，那么所有的 **参与者** 还都处于

锁定事务资源的状态中，而无法继续完成事务操作。（虽然协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）

**2PC出现单点问题的三种情况**

(1)`协调者正常,参与者宕机`

由于 **协调者** 无法收集到所有 **参与者** 的反馈，会陷入阻塞情况。

**解决方案**:引入超时机制,如果协调者在超过指定的时间还没有收到参与者的反馈,事务就失败,向所有节点发送终止事务请求。

(2)`协调者宕机,参与者正常`

无论处于哪个阶段，由于**协调者宕机**，无法发送提交请求，所有处于执行了操作但是未提交状态的参与者都会陷入阻塞情况.

**解决方案**:引入协调者备份,同时协调者需记录操作日志.当检测到协调者宕机一段时间后，协调者备份取代协调者，并读取操作日志，向所有参与者询问状态。

(3)`协调者和参与者都宕机`

1.  **发生在第一阶段**： 因为第一阶段，所有参与者都没有真正执行commit，所以只需重新在剩余的参与者中重新选出一个协调者，新的协调者在重新执行第一阶段和第二阶段就可以了。

2)**发生在第二阶段 并且 挂了的参与者在挂掉之前没有收到协调者的指令**。也就是上面的第4步挂了，这是可能协调者还没有发送第4步就挂了。这种情形下，新的协调者重新执行第一阶段和第二阶段操作。

3)**发生在第二阶段 并且 有部分参与者已经执行完commit操作**。就好比这里订单服务A和支付服务B都收到**协调者** 发送的commit信息，开始真正执行本地事务commit,但突发情况，Acommit成功，B确挂了。这个时候目前来讲数据是不一致的。虽然这个时候可以再通过手段让他和协调者通信，再想办法把数据搞成一致的，但是，这段时间内他的数据状态已经是不一致的了！ 2PC 无法解决这个问题。

## **二、三阶段提交(3PC)** ##

三阶段提交协议（3PC）主要是为了解决两阶段提交协议的阻塞问题，2pc存在的问题是当协作者崩溃时，参与者不能做出最后的选择。因此参与者可能在协作者恢复之前保持阻塞。三阶段提交（Three-phase commit），是二阶段提交（2PC）的改进版本。

与两阶段提交不同的是，三阶段提交有两个改动点。

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

也就是说，除了引入超时机制之外，**3PC把2PC的准备阶段再次一分为二**，这样三阶段提交就有`CanCommit`、`PreCommit`、`DoCommit`三个阶段。

**1、CanCommit阶段**

之前2PC的一阶段是本地事务执行结束后，最后不Commit,等其它服务都执行结束并返回Yes，由协调者发生commit才真正执行commit。而这里的CanCommit指的是 **尝试获取数据库锁** 如果可以，就返回Yes。

![b3df48b48db1c589a78ce8980eaff41a.png][]

这阶段主要分为2步

`事务询问` **协调者** 向 **参与者** 发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待 **参与者** 的响应。  
`响应反馈` **参与者** 接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No

**2、PreCommit阶段**

在阶段一中，如果所有的参与者都返回Yes的话，那么就会进入PreCommit阶段进行事务预提交。这里的**PreCommit阶段** 跟上面的第一阶段是差不多的，只不过这里 **协调者和参与者都引入了超时机制** （2PC中只有协调者可以超时，参与者没有超时机制）。

**3、DoCommit阶段**

这里跟2pc的阶段二是差不多的。

`总结`

相比较2PC而言，3PC对于协调者（**Coordinator**）和参与者（**Partcipant**）都设置了超时时间，而2PC只有协调者才拥有超时机制。这解决了一个什么问题呢？

这个优化点，主要是避免了参与者在长时间无法与协调者节点通讯（协调者挂掉了）的情况下，无法释放资源的问题，因为参与者自身拥有超时机制会在超时后，

自动进行本地commit从而进行释放资源。而这种机制也侧面降低了整个事务的阻塞时间和范围。

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

以上就是3PC相对于2PC的一个提高（相对缓解了2PC中的前两个问题），但是3PC依然没有完全解决数据不一致的问题。

### **参考** ###

1、[分布式事务：深入理解什么是2PC、3PC][2PC_3PC]

2、[分布式事务、3pc][3pc]

3、[对分布式事务及两阶段提交、三阶段提交的理解][Link 1]

4、[分布式理论基础：2PC和3PC][2PC_3PC 1]

[c3c5e917447a583d83da4451c75c6eaa.png]: /images/20221120/016c9b25d9724f21b7dcb271376250d0.png
[e3ade8abfb29ee74e94b6112b7f096e1.png]: https://img-blog.csdnimg.cn/img_convert/e3ade8abfb29ee74e94b6112b7f096e1.png
[b67c41099678e7bda4a88a5cf82f777a.png]: https://img-blog.csdnimg.cn/img_convert/b67c41099678e7bda4a88a5cf82f777a.png
[b3df48b48db1c589a78ce8980eaff41a.png]: https://img-blog.csdnimg.cn/img_convert/b3df48b48db1c589a78ce8980eaff41a.png
[2PC_3PC]: http://www.sohu.com/a/290897501_684445
[3pc]: https://www.jianshu.com/p/0829d8abccdf
[Link 1]: https://www.cnblogs.com/binyue/p/3678390.html
[2PC_3PC 1]: https://www.cnblogs.com/zcjcsl/p/7989792.html