分布式事务的解决方案

逃离我推掉我的手 2023-01-17 06:29 135阅读 0赞

# 两阶段提交/XA #

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

目前，绝大部分的关系型数据库都是采用二阶段提交协议 来完成分布式事务处理的，利用该协议能够非常方便地完成所有分布式事务参与者的协 调，统一决定事务的提交或回滚，从而能够有效地保证分布式数据一致性，因此二阶段 提交协议被广泛地应用在许多分布式系统中。

### 协议说明 ###

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

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

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

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

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

执行事务提交

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

1.  发送提交请求。  
    协调者向所有参与者节点发出 Commit 请求。
2.  事务提交。  
    参与者接收到 Commit 请求后，会正式执行事务提交操作，并在完成提交之 后释放在整个事务执行期间占用的事务资源。
3.  反馈事务提交结果。  
    参与者在完成事务提交之后，向协调者发送 Ack 消息。
4.  完成事务。  
    协调者接收到所有参与者反馈的 Ack 消息后，完成事务。
    
    ![在这里插入图片描述][20210427132632626.png]

中断事务

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

1.  发送回滚请求。  
    协调者向所有参与者节点发出 Rollback 请求。
2.  事务回滚。  
    参与者接收到 Rollback 请求后，会利用其在阶段一中记录的 Undo 信息来执 行事务回  
    滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源。
3.  反馈事务回滚结果。  
    参与者在完成事务回滚之后，向协调者发送 Ack 消息。
4.  中断事务。  
    协调者接收到所有参与者反馈的 Ack 消息后，完成事务中断。以上就是二阶段提交过程中，前后两个阶段分别进行的处理逻辑。简单地讲，二阶段提 交将一个事务的处理过程分为了投票和执行两个阶段，其核心是对每个事务都采用先尝 试后提交的处理方式，因此也可以将二阶段提交看作一个强一致性的算法
    
    ![在这里插入图片描述][20210427132700667.png]

### 优缺点 ###

*  二阶段提交协议的优点：原理简单，实现方便。
 *  二阶段提交协议的缺点：同步阻塞、单点问题、脑裂、太过保守。

**同步阻塞**  
二阶段提交协议存在的最明显也是最大的一个问题就是同步阻塞，这会极大地限制 分布式系统的性能。在二阶段提交的执行过程中，所有参与该事务操作的逻辑都处 于阻塞状态，也就是说，各个参与者在等待其他参与者响应的过程中，将无法进行 其他任何操作。

**单点问题**  
在上面的讲解过程中，相信读者可以看出，协调者的角色在整个二阶段提交协议中 起到了非常重要的作用。一旦协调者出现问题，那么整个二阶段提交流程将无法运 转，更为严重的是，如果协调者是在阶段二中出现问题的话，那么其他参与者将会 一直处于锁定事务资源的状态中，而无法继续完成事务操作。

**数据不一致**  
在二阶段提交协议的阶段二，即执行事务提交的时候，当协调者向所有的参与者发 送Commit 请求之后，发生了局部网络异常或者是协调者在尚未发送完 Commit 请求 之前自身发生了崩溃，导致最终只有部分参与者收到了 Commit 请求。于是，这部分 收到了Commit 请求的参与者就会进行事务的提交，而其他没有收到 Commit 请求的 参与者则无法进行事务提交，于是整个分布式系统便出现了数据不一致性现象。

**太过保守**  
如果在协调者指示参与者进行事务提交询问的过程中，参与者出现故障而导致协调 者始终无法获取到所有参与者的响应信息的话，这时协调者只能依靠其自身的超时 机制来判断是否需要中断事务，这样的策略显得比较保守。换句话说，二阶段提交 协议没有设计较为完善的容错机制，任意一个节点的失败都会导致整个事务的失败。

# 3PC #

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

### 协议说明 ###

3PC, 是 Three-Phase Commit 的缩写，即三阶段提交，是 2PC 的改进版，其将二阶段提 交协议的“提交事务请求”过程一分为二，形成了由 CanCommit 、 PreCommit 和 do Commit 三个阶段组成的事务处理协议

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70][]

**阶段一： CanCommit**

*  事务询问：协调者向所有的参与者发送一个包含事务内容的 canCommit 请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
 *  各参与者向协调者反馈事务询问的响应：参与者接收来自协调者的 canCommit 请求，如果参与者认为自己可以顺利执行事务，就返回 Yes，否则反馈 No 响应。

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

执行事务预提交

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

1.  发送预提交请求：协调者向所有参与者节点发出 preCommit 的请求，并进入 prepared 状态。
2.  事务预提交：参与者受到 preCommit 请求后，会执行事务操作，对应 2PC 中的 “执行事务（即 2PC 第一个阶段）”，也会 Undo 和 Redo 信息记录到事务日志中。
3.  各参与者向协调者反馈事务执行的结果：如果参与者成功执行了事务，就反馈 Ack 响应，同时等待指令：提交（commit） 或终止（abor）。

中断事务

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

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

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

执行提交

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

中断事务

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

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

需要注意的是，一旦进入阶段三

*  可能会存在以下两种故障。
    
     *  协调者出现问题。
     *  协调者和参与者之间的网络出现故障。
 *  无论出现哪种情况，最终都会导致参与者无法及时接收到来自协调者的 doCommit 或是 abort 请  
    求，针对这样的异常情况，参与者都会在等待超时之后，继续进行事务提交。

### 优缺点 ###

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

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

# TCC #

关于 TCC（Try-Confirm-Cancel） 事务机制相比于上面介绍的 XA，解决了其几个缺点：

1.  解决了协调者单点，由主业务方发起并完成这个业务活动。业务活动管理器也变成多点，引入集群。
2.  同步阻塞：引入超时，超时后进行补偿，并且不会锁定整个资源，将资源转换为业务逻辑形式，粒度变小。
3.  数据一致性，有了补偿机制之后，由业务活动管理器控制一致性

TCC(Try Confirm Cancel)

*  Try 阶段：尝试执行，完成所有业务检查（一致性）, 预留必须业务资源（准隔离性）
 *  Confirm 阶段：确认执行真正执行业务（一般会调用远程服务），不作任何业务检查，只使用 Try 阶段预留的业务资源，Confirm 操作满足幂等性。要求具备幂等设计，Confirm 失败后需要进行重试。
 *  Cancel 阶段：取消执行，释放 Try 阶段预留的业务资源 Cancel 操作满足幂等性 Cancel 阶段的异常和 Confirm 阶段异常处理方案基本上一致。

## 本地消息表 ##

该方案中会有消息生产者与消费者两个角色，假设系统 A 是消息生产者，系统 B 是消息消费者，其大致流程如下：

![9cf06b226f838c1844413f25632c5bef.png][]

1.  当系统 A 被其他系统调用发生数据库表更操作，首先会更新数据库的业务表，其次会往相同数据库的消息表中插入一条数据，两个操作发生在同一个事务中
2.  系统 A 的脚本定期轮询本地消息往 mq 中写入一条消息，如果消息发送失败会进行重试
3.  系统 B 消费 mq 中的消息，并处理业务逻辑。如果本地事务处理失败，会在继续消费 mq 中的消息进行重试，如果业务上的失败，可以通知系统 A 进行回滚操作

本地消息表实现的条件：

1.  消费者与生成者的接口都要支持幂等
2.  生产者需要额外的创建消息表
3.  需要提供补偿逻辑，如果消费者业务失败，需要生产者支持回滚操作

容错机制：

1.  步骤 1 失败时，事务直接回滚
2.  步骤 2、3 写 mq 与消费 mq 失败会进行重试
3.  步骤 3 业务失败系统 B 向系统 A 发起事务回滚操作

此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列，再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景，通过对账系统对事后问题的处理。

## 可靠消息最终一致性（MQ 事务） ##

大致流程如下：

![5edb9b33c40845fb99ed34b9446039de.png][]

1.  A 系统先向 mq 发送一条 prepare 消息，如果 prepare 消息发送失败，则直接取消操作
2.  如果消息发送成功，则执行本地事务
3.  如果本地事务执行成功，则想 mq 发送一条 confirm 消息，如果发送失败，则发送回滚消息
4.  B 系统定期消费 mq 中的 confirm 消息，执行本地事务，并发送 ack 消息。如果 B 系统中的本地事务失败，会一直不断重试，如果是业务失败，会向 A 系统发起回滚请求
5.  5.mq 会定期轮询所有 prepared 消息调用系统 A 提供的接口查询消息的处理情况，如果该 prepare 消息本地事务处理成功，则重新发送 confirm 消息，否则直接回滚该消息

该方案与本地消息最大的不同是去掉了本地消息表，其次本地消息表依赖消息表重试写入 mq 这一步由本方案中的轮询 prepare 消息状态来重试或者回滚该消息替代。其实现条件与余容错方案基本一致。目前市面上实现该方案的只有阿里的 RocketMq。

### 尽最大努力通知 ###

最大努力通知型( Best-effort delivery)是最简单的一种柔性事务，适用于一些最终一致性时间敏感度低的业务，且被动方处理结果 不影响主动方的处理结果。典型的使用场景：如银行通知、商户通知等。最大努力通知型的实现方案，一般符合以下特点：

1.  不可靠消息：业务活动主动方，在完成业务处理之后，向业务活动的被动方发送消息，直到通知N次后不再通知，允许消息丢失(不可靠消息)。
2.  定期校对：业务活动的被动方，根据定时策略，向业务活动主动方查询(主动方提供查询接口)，恢复丢失的业务消息。

这个方案的大致意思就是：

1.  系统 A 本地事务执行完之后，发送个消息到 MQ；
2.  这里会有个专门消费 MQ 的服务，这个服务会消费 MQ 并调用系统 B 的接口；
3.  要是系统 B 执行成功就 ok 了；要是系统 B 执行失败了，那么最大努力通知服务就定时尝试重新调用系统 B, 反复 N 次，最后还是不行就放弃，因为调用方 A 也会定期轮询 B 的执行结果。

# 总结 #

分布式事务本身就是一个技术难题，业务中具体使用哪种方案还是需要根据自身业务特点自行选择，每种方案在实际执行过程中需要考虑的点都非常多，复杂度较大，所以在非必要的情况下，分布式事务能不用就尽量不用。

[20210427132632626.png]: /images/20221021/edef7c9d732345168441e1abbe3e5777.png
[20210427132700667.png]: /images/20221021/b6d8a33f546449f19632677fa3b2ca10.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70]: /images/20221021/066f49e4cc8545b18d1ab7dab3a84b2f.png
[9cf06b226f838c1844413f25632c5bef.png]: /images/20221021/6f31be7d2bf44fa8aac64aa4ac290757.png
[5edb9b33c40845fb99ed34b9446039de.png]: /images/20221021/12838975422e4670a92f8092a9f6ca82.png