消息队列与分布式事务：探讨不同MQ如何实现可靠消息最终一致性

原创

已于 2024-09-01 15:35:13 修改 · 1.7k 阅读

26 ·

CC 4.0 BY-SA版权

文章标签：

#分布式

于 2024-08-17 13:37:15 首次发布

文章目录

分布式事务系列文章
初探分布式事务：扫盲分布式事务的基础概念和理论知识点
图解分布式事务中的2PC与Seata方案
案例驱动学习：轻松理解TCC分布式事务
消息队列与分布式事务：探讨不同MQ如何实现分布式事务的可靠消息传递
MQ最大努力通知VS可靠性消息一致性：分布式事务中的区别与应用比较
分布式事务方案比较：选择适合你的分布式事务策略！

文章导图

在这里插入图片描述

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

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

此方案是利用消息中间件完成，如下图：
在这里插入图片描述

事务发起方（消息生产方）将消息发给消息中间件，事务参与方从消息中间件接收消息，事务发起方和消息中间件之间，事务参与方（消息消费方）和消息中间件之间都是通过网络通信，由于网络通信的不确定性会导致分布式事务问题。

需要解决的三个问题

可靠消息最终一致性方案要解决以下几个问题：

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

本地事务与消息发送的原子性问题即：事务发起方在本地事务执行成功后消息必须发出去，否则就丢弃消息。即实现本地事务和消息发送的原子性，要么都成功，要么都失败。本地事务与消息发送的原子性问题是实现可靠消息最终一致性方案的关键问题。

先来尝试下这种操作，先发送消息，再操作数据库：

begin transaction；
//1.发送MQ
//2.数据库操作
commit transation;

这种情况下无法保证数据库操作与发送消息的一致性，因为可能发送消息成功，数据库操作失败。

你立马想到第二种方案，先进行数据库操作，再发送消息：

begin transaction；
//1.数据库操作
//2.发送MQ
commit transation;

这种情况下貌似没有问题，如果发送MQ消息失败，就会抛出异常，导致数据库事务回滚。但如果是超时异常，数据库回滚，但MQ其实已经正常发送了，同样会导致不一致。

2、事务参与方接收消息的可靠性

事务参与方必须能够从消息队列接收到消息，如果接收消息失败可以重复接收消息。

3、消息重复消费的问题

由于网络的存在，若某一个消费节点超时但是消费成功，此时消息中间件会重复投递此消息，就导致了消息的重复消费。

要解决消息重复消费的问题就要实现事务参与方的方法幂等性。

解决方案

上面讨论了可靠消息最终一致性事务方案需要解决的问题，本节讨论具体的解决方案。

本地消息表方案

本地消息表这个方案最初是eBay提出的，此方案的核心是通过本地事务保证数据业务操作和消息的一致性，然后通过定时任务将消息发送至消息中间件，待确认消息发送给消费方成功再将消息删除。

下面以注册送积分为例来说明：

下例共有两个微服务交互，用户服务和积分服务，用户服务负责添加用户，积分服务负责增加积分。

交互流程如下：

在这里插入图片描述

1、用户注册

用户服务在本地事务新增用户和增加 ”积分消息日志“。（用户表和消息表通过本地事务保证一致）

下边是伪代码

begin transaction；
//1.新增用户
//2.存储积分消息日志
commit transation;

这种情况下，本地数据库操作与存储积分消息日志处于同一个事务中，本地数据库操作与记录消息日志操作具备原子性。

2、定时任务扫描日志

如何保证将消息发送给消息队列呢？

经过第一步消息已经写到消息日志表中，可以启动独立的线程，定时对消息日志表中的消息进行扫描并发送至消息中间件，在消息中间件反馈发送成功后删除该消息日志，否则等待定时任务下一周期重试。

3、消费消息

如何保证消费者一定能消费到消息呢？

这里可以使用MQ的ack（即消息确认）机制，消费者监听MQ，具体可以分为两种情况（以springboot工程为例）：

spring:
  rabbitmq:
    listener:
      simple:
        acknowledge-mode: manual  # 手动ack-manual
		# acknowledge-mode: auto  #自动ack-auto
	  retry:
          enabled: true
          max-attempts: 3   # 一定要设置最大重试次数，不然发生异常会一直重试

手动ack: 如果消费者接收到消息并且业务处理完成后向MQ发送ack（即消息确认），此时说明消费者正常消费消息完成，MQ将不再向消费者推送消息；如果发生异常，则进行channel.basicNack() 或 channel.basicReject() 方法拒绝消息, 同时要注意 void basicNack(long deliveryTag, boolean multiple, boolean requeue) 最后一个requeue=true，才会重新入队进行消费
```
@RabbitListener(queues = RabbitMqConfig.QUEUE_NAME1)
    public void handleMessage(Channel channel, Message message){
     
     
        // 处理消息
		try {
     
     
			System.
```