分布式事务：可靠消息最终一致性方案

客官°小女子只卖身不卖艺 2022-09-08 15:59 194阅读 0赞

大家好，我是田维常，江湖人称老田、田哥、田神，一个爱打球的程序员。

> 事务想必大家并不陌生，比如经常被人提起的`ACID`，但是为了后续的`分布式事务`的内容，我们先来聊聊 `ACID`，然后再介绍下什么是`分布式事务`，最后着重讲下基于`可靠消息`的分布式事务解决方案。

### 什么是事务 ###

严格意义上的事务应该是具备原子性、一致性、隔离性和持久性，简称 `ACID`。

1.  `原子性（Atomicity）`，可以理解为一个事务内的所有操作要么都执行，要么都不执行。
2.  `一致性（Consistency）`，可以理解为数据是满足完整性约束的，也就是不会存在中间状态的数据，比如你钱包有100，我钱包有100，你给我打50块，此时你钱包的钱应该是50，我钱包的钱应该是150，不会存在我钱加了，你钱没扣的中间状态。
3.  `隔离性（Isolation）`，指的是多个事务并发执行的时候不会互相干扰，即一个事务内部的数据对于其他事务来说是隔离的。
4.  `持久性（Durability）`，指的是一个事务完成了之后数据就被永远保存下来，之后的其他操作或故障都不会对事务的结果产生影响。

而通俗意义上事务就是为了使得一些更新操作`要么都成功，要么都失败`。

### 什么是分布式事务 ###

`分布式事务`顾名思义就是要在分布式系统中实现事务，它其实是由多个`本地事务`组合而成。

一次大的操作由不同的小操作组成的，这些小的操作分布在不同的服务器上，`分布式事务`需要保证这些小操作要么全部成功，要么全部失败。从本质上来说，`分布式事务`就是为了保证`不同数据库`的`数据一致性`。

常见的分布式事务的解决方案有以下几种:`2PC,3PC,TCC,本地消息表、可靠消息最终一致性、尽最大努力通知`等

今天我们就着重讲讲`可靠消息最终一致性的解决方案`

### 什么是可靠消息最终一致性方案 ###

`可靠消息最终一致性方案`是指当事务发起方执行完成本地事务后发出消息到`消息中间件`，`事务参与方(消息消费者)`一定能够接收到消息并处理事务成功，此方案强调的是`只要消息发给事务参与方，则最终事务要达到一致`。

#### 这个方式存在哪些问题？ ####

此方案是通过消息中间件实现的，事务发起方（消息生产方）将消息发给消息中间件，事务参与方从消息中间件接收消息，由于网络通信的不确定性会导致分布式事务问题，如下图：

![11e7e990c333781fd09a4fb38ff56d94.png][]

1.  本地事务与消息的原子性问题

![3d32d91ab0a0c61981a4f1aa788ad021.png][]

如上图在虚线框内，存在以下几种情况：

> 1）本地事务提交失败，则消息不发送。  
> 2）本地事务成功，消息发送失败，本地事务回滚。  
> 3）本地消息成功，消息超时，本地事务回滚，消息最终失败。  
> 4）本地消息成功，消息超时，本地事务回滚，消息最终成功。  
>

综上所述，存在`第四种情况`，造成本地事务，与消息参与方的事务不一致。

1.  事务参与方接收消息的可靠性。

消息中间件与`事务参与方`要确保能够`成功消费`到消息。

1.  消息重复消费

注意事务参与方的`接口幂等性`问题，消息参与方可能已经成功消费，由于网络问题导致消息中间件认为消息未消费，发起重试之后产生的问题。

#### 解决方案 ####

1.  本地消息表

本地消息表的关键在于本地有一张存储消息日志的记录表，需要启动一个定时任务去不停地扫描消息日志记录，确保消息能够被发送。具体流程如下图：

![7d6e75553b7bf1592423eb2e244fc937.png][]

上图流程：

> 1）事务发起方本地事务执行成功，在本地消息表中记录消息日志。  
> 2）启动定时任务，循环扫描本地消息表。  
> 3）定时任务扫描到消息则发送消息到消息中间件。  
> 4）消息中间件收到消息，成功返回消息发送成功通知给事务发起方。  
> 5）事务发起方收到消息发送成功则删除日志消息。  
> 6）事务参与方订阅消息，消费消息。  
> 7）事务参与方处理本地事务。  
> 8）本地事务处理成功，发送成功ack给消息中间件。  
>

需要注意的点:  
`事务参与方保证接口幂等性`。

1.  RocketMq事务消息方案

Apache `RocketMQ` 4.3之后的版本正式支持`事务消息`，为分布式事务实现提供了便利性支持。在RocketMQ 4.3后实现了完整的事务消息，实际上其实是`对本地消息表的一个封装`，将本地消息表移动到了`MQ内部`，解决 Producer 端的消息发送与本地事务执行的`原子性`问题。

![dcb2b012d5f95c26e13439611f17ddd3.png][]

实现流程：

> 1）事务发起方发送`Half`事务消息  
> 2）RocketMq回复`Half`发送成功  
> 3）事务发起方执行本地事务  
> 4）事务发起方执行本地事务成功，发送commit到RocketMq，mq投递消息到事务参与方；事务发起方执行本地事务失败，发送`rollback`到RocketMq，mq删除消息。  
> 5）当RocketMq一定时间内未收到来自事务发起方的确认信息，会对事务发起方进行`事务回查`。  
> 6）事务发起方查询本地事务状态。  
> 7）事务发起方根据查询到的事务状态发送`commint/rollback`到RocketMq。  
> 8）当RocketMq发起`commit`后，收到失败或一定时间未收到成功ack，则会发起重试。

`优点`：

消息数据独立存储，降低业务系统与消息系统之间的耦合。  
吞吐量优于本地消息表方案。

`缺点`：

一次消息发送需要两次网络请求(half消息 + commit/rollback)。  
需要实现消息回查接口。

其实每种分布式事务的解决方案都有优劣，我们需要权衡利弊，选择最合适业务场景的一种才是王道！

--------------------

好了。今天就说到这了，我还会不断分享自己的所学所想，希望我们一起走在成功的道路上！

转发朋友圈是对我最大的支持！

![1b9c23f5f4fcac5bf599729b4c8cd603.png][]

觉得有点东西就点一下“赞和在看”吧！感谢大家的支持了！

[11e7e990c333781fd09a4fb38ff56d94.png]: /images/20220829/bd394d22e19a459ba5e2ad1032ac5f6f.png
[3d32d91ab0a0c61981a4f1aa788ad021.png]: /images/20220829/7b17210cecf044d5b1f651dfd2d70f94.png
[7d6e75553b7bf1592423eb2e244fc937.png]: /images/20220829/4c4a2a54eeb14e1ea1c4bba8024cb48a.png
[dcb2b012d5f95c26e13439611f17ddd3.png]: /images/20220829/89e33c33101b475d9ad03745c629e6ac.png
[1b9c23f5f4fcac5bf599729b4c8cd603.png]: /images/20220829/49b3bbb089394a2da3b2be9135df0b32.png