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

末蓝、 2023-10-13 23:09 86阅读 0赞

#### 文章目录 ####

*  前言
 *  1.分布式理论：一致性协议：2PC
 *   *  1.1 什么是2PC
     *  1.2. 两个阶段过程：
     *  1.4. 2PC执行流程
     *  1.5. 2PC的优点和缺点:
 *  2.什么是3PC
 *   *  2.1. 阶段一：CanCommit
     *  2.2. 阶段二：PreCommit
     *  2.3. 阶段三：do commit
     *  2.4. 3PC的优点和缺点：
 *  3.两阶段提交 VS 三阶段提交
 *  4.数据一致性问题和解决方案
 *   *  4.1 Paxos 算法
     *  4.2 柔性事务
 *  总结

## 前言 ##

在分布式事务中，通常使用两阶段协议或三阶段协议来保障分布式事务的正常运行，它也是 X/Open 公司定义的一套分布式事务标准。

> X/Open 公司是由多家国际计算机厂商所组成的联盟组织，它建立之初是为了向 UNIX 环境提供标准。

分布式事务是指在分布式系统中，多个节点之间进行的事务操作。比如在分布式系统中，用户在下单时，需要同时创建订单信息和减库存的操作，然而创建订单信息和减库存是分布在不同服务器和不同数据库中的，如下图所示：  
![在这里插入图片描述][d844446c1a6a4706accfe583154a6325.png]  
此时我们就需要一个分布式事务介入，保证所有操作，要么一起提交，要么一起回滚。

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

### 1.1 什么是2PC ###

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

### 1.2. 两个阶段过程： ###

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

### 1.4. 2PC执行流程 ###

成功执行事务事务提交流程 ，如下  
![在这里插入图片描述][b8074efbf6974e459c348f4a15918d33.png]

*  阶段一:

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三个阶段组成的事务处理协议  
![在这里插入图片描述][bacb161c46da45dab5f51d50344ffabe.png]

### 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 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ZEWENHX1g_size_16_color_FFFFFF_t_70]

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

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是一个缓冲，保证了在最后提交阶段之前各参与节点的状态是一致的

![在这里插入图片描述][ad73a3549fb84d2e93cc2632766bf67b.png]

## 3.两阶段提交 VS 三阶段提交 ##

2PC 和 3PC 是分布式事务中两种常见的协议，3PC 可以看作是 2PC 协议的改进版本，相比于 2PC 它有两点改进：

1.  引入了超时机制，同时在协调者和参与者中都引入超时机制（2PC 只有协调者有超时机制）；
2.  3PC 相比于 2PC 增加了 CanCommit 阶段，可以尽早的发现问题，从而避免了后续的阻塞和无效操作。

也就是说，3PC 相比于 2PC，因为引入了超时机制，所以发生阻塞的几率变小了；同时 3PC 把之前 2PC 的准备阶段一分为二，变成了两步，这样就多了一个缓冲阶段，保证了在最后提交阶段之前各参与节点的状态是一致的。

## 4.数据一致性问题和解决方案 ##

3PC 虽然可以减少同步阻塞问题和单点故障问题，但依然存在数据一致性问题（概率很小），而解决数据一致性问题的方案有很多，比如 Paxos 算法或柔性事物机制等。

### 4.1 Paxos 算法 ###

Paxos 算法是一种基于消息传递的分布式一致性算法，并在 2013 年获得了图灵奖。

图灵奖（ACM A.M. Turing Award）是计算机科学领域最高荣誉之一，由美国计算机协会（ACM）于 1966 年设立，每年颁发一次，表彰对计算机科学领域做出杰出贡献的人士或团体。

简单来说，Paxos 算法是一种分布式共识算法，用于在分布式系统中实现数据的一致性和共识，保证分布式系统中不同节点之间的数据同步和一致性。

Paxos 算法由三个角色组成：提议者、接受者和学习者。当一个节点需要发起一个提议时，它会向其他节点发送一个提议，接受者会接收到这个提议，并对其进行处理，可能会拒绝提议，也可能会接受提议。如果有足够多的节点接受了该提议，那么提议就会被确定下来，并且通知给所有学习者，最终所有节点都会达成共识。

Paxos 算法看起来很简单，但它实际上是非常的复杂。

Paxos 算法应用的产品也很多，比如以下几个：

*  Redis：Redis 是一个内存数据库，使用 Paxos 算法实现了分布式锁服务和主从复制等功能。
 *  MySQL：MySQL 5.7 推出的用来取代传统的主从复制的 MySQL Group Replication 等。
 *  ZooKeeper：ZooKeeper 是一个分布式协调服务，使用 Paxos 算法实现了分布式锁服务和数据一致性等功能。
 *  Apache Cassandra：Cassandra 是一个分布式数据库系统，使用 Paxos 算法实现了数据的一致性和复制等功能。
 *  Google Chubby：Chubby 是 Google 内部使用的分布式锁服务，使用 Paxos 算法实现了分布式锁服务和命名服务等功能。

### 4.2 柔性事务 ###

柔性事务机制：允许一定时间内不同节点的数据不一致，但要求最终一致的机制。  
柔性事物有 TCC 补偿事物、可靠消息事物（MQ 事物）等。

## 总结 ##

在分布式事务中，通常使用两阶段或三阶段提交协议来保障分布式事务的正常执行。两阶段协议包含准备阶段和提交阶段，然而它存在同步阻塞问题、单点故障和数据一致性问题。而三阶段协议可以看作是两阶段协议的改进版，它将两阶段的准备阶段一分为二，多了一个询问阶段，保证了提交阶段之前各参与节点的状态是一致的，同时引入了超时机制，减少了同步阻塞问题发生的几率。但 2PC 和 3PC 都存在数据一致性问题，此时可以采用 Paxos 算法或柔性事务机制等方案来解决事务一致性问题。

[d844446c1a6a4706accfe583154a6325.png]: https://img-blog.csdnimg.cn/d844446c1a6a4706accfe583154a6325.png
[b8074efbf6974e459c348f4a15918d33.png]: https://img-blog.csdnimg.cn/b8074efbf6974e459c348f4a15918d33.png
[bacb161c46da45dab5f51d50344ffabe.png]: https://img-blog.csdnimg.cn/bacb161c46da45dab5f51d50344ffabe.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ZEWENHX1g_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20210326162136165.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ZEWENHX1g=,size_16,color_FFFFFF,t_70
[ad73a3549fb84d2e93cc2632766bf67b.png]: https://img-blog.csdnimg.cn/ad73a3549fb84d2e93cc2632766bf67b.png