如何保证线上MQ消息不丢失

心已赠人 2024-02-18 13:38 21阅读 0赞

#### 如何保证线上MQ消息不丢失 ####

*  MQ的应用场景
 *  涉及的三个角色
 *  以RocketMQ为例
 *   *  1. 生产者维度
     *   *  三种发送消息的方式
     *  2. MQ
     *   *  两种不同的消息落盘方式
     *  3. 消费者
     *   *  开启ACK确认机制

## MQ的应用场景 ##

对于订单超时未支付的问题，业内最主流的一种解决方案就是通过MQ来实现。

## 涉及的三个角色 ##

首先我们可以看见整个过程我们是有三个角色，生产者、MQ和我们的消费者。

我们要保证我们的消息不丢失，那么这三个维度它都要去进行分析。因为这三个维度都可能会导致一个问题的产生。

而且我们不同的消息中间件，它所产生的问题和解决方案也是不一样的。

## 以RocketMQ为例 ##

那么在这里就以RocketMQ来举例，虽然说有点差异，但是整体上是一样的。

### 1. 生产者维度 ###

我们首先来分析第一个维度，就是我们的生产者维度，我们的程序，那么它作为一个生产者的话，我们把消息通过我们生产者发送给我们MQ。那么网络呢，我们都知道它是不可靠的。假设我们发生了网络抖动，我们发送的消息很有可能会导致丢失。

那我们在生产者这一侧，怎么去保证它消息不会被丢失呢。

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

#### 三种发送消息的方式 ####

首先我们RocketMQ是为我们提供了三种发送消息的一个方式：  
![在这里插入图片描述][e106059c8f6343279fd6c93a72239813.png]

1.  同步发送  
    我们生产者向MQ它发送消息，它会阻塞我们当前的一个线程，也就是说我们必须拿到MQ返回给我们的一个结果之后，然后整个过程呢它才算一个结束。
2.  异步发送  
    它是先构建的一个发送消息的一个任务，然后它把任务丢到了线程池，它丢完之后就直接返回。我已经发送完成了。但是实际上它并没有去执行完成，只有说当我们MQ处理完了之后，然后返回给我们消费者，它会通过一个回调函数告诉我们执行处理的一个结果。那么这个就是异步发送。
3.  Oneway发送  
    它只负责发送请求，不用等待我们返回。那么也就是它不需要去处理我们返回的一个结果。

以上三种方案在遇到网络抖动之后，Oneway发送方式会发生消息丢失的情况。如果我们在业务上，那么它必须要保证消息记录不能丢失的话，我们尽量还是不要用Oneway这种方式。

如果说我们是类似于日志之类的一些消息，那么丢几条也没有关系。而且消息量很大，要尽可能地我们要去提升它的一个发送的性能。我们可以去采用Oneway这种方式来去使用。毕竟我们的Oneway模式它不需要去等待返回。那么在性能上面，它是比我们同步发送和异步发送是快一些的。

所以一般情况下来说，我们要保证消息不丢失的话，我们要去使用同步方式，那么这个是根据我们业务在性能上面和可用性上面，它去做了一个平衡。可能也有一些情况，比如说生产者发送还没有接收到响应，它已经挂了，那么这个就不在我们考虑范围之类了。我们主要考虑的是我们消息的一个丢失的问题。

### 2. MQ ###

上一部分是关于生产者的，接下来看一看RocketMQ在什么情况下面会导致我们消息丢失的一个问题。

RocketMQ的**消息数据是放在磁盘里面的**。但是RocketMQ为了保证消息的一个处理速度，它**默认**是采用了**异步刷盘**的一个策略。

#### 两种不同的消息落盘方式 ####

![在这里插入图片描述][8dbae365fc1c4541b2d2b6e14125c9f9.png]  
这两张图是我们RocketMQ消息落盘的两种不同的策略和方式。

采用**异步刷盘**的策略是为了让**性能**比同步刷盘高一些。那么接收到响应结果之后，我们直接将数据放在内存里面，我们就可以返回了。

这个时候如果我们MQ它所在的一个服务器发生了宕机或者说断电了或者说MQ本身服务挂了。它都有可能会导致我们消息的一个丢失。因为我们的内存是不能持久化的。

如果我们要去保证MQ本身消息不丢失的话，那么我们可以去修改RocketMQ它本身的存储策略。我们可以**把异步刷盘改成同步刷盘**。

**只有刷盘成功了，我们才去返回给我们的生产者**。那么这样，我们就可以保证在返回之前，我们的数据就已经落在磁盘里面了。

但是磁盘坏的情况如何应对呢？  
这个时候我们可以采用RocketMQ的主从架构来进行集群部署。Master中的一个数据是在多个Slaver节点里面都是有备份的。这样尽管我们一个节点挂了，那么我们也能够去避免我们单点故障的一个问题。

### 3. 消费者 ###

以上是RocketMQ本身的消息不丢失的方案，下面来看消费者如何去保证消息不丢失的。

实际上是非常简单的。因为在很多情况下面，我们的消费者它为了保证消息速度，它可能没有开启我们ACK确认机制，我们只要获取到消息那么就算成功了。这个时候如果说消费者宕机了或者说所在机器宕机了，就有可能会导致我们消息它没有被正确地处理掉。

#### 开启ACK确认机制 ####

解决这个问题很简单，我们可以**直接使用ACK确认机制**。只有当我们的消息成功处理了之后，我们才去返回一个确认，这样呢我们就能够去避免我们丢失消息的问题，这样也不是没有缺点。因为我们采用了ACK确认之后，它就有可能会导致我们**性能的下降**，同时也有可能会导致**重复消息**的一个问题。

**重复消息问题**只要在**业务上保证幂等性**就可以搞定了。当然我们业务在处理的时候，也不可能就是一帆风顺，可能也有其他的一些中间件，它有可能会出问题。数据库也有可能会出问题，这个时候我们可以去使用RocketMQ的一个消息自动重试机制来进行处理。

当然重试的时间和重试的次数都是可以去进行配置的。

**参考资料**：[字节二面：引入MQ后，你怎么保证线上消息100%不丢失 ？][MQ_100_]

[5471d1cd8bef40e784f8c5af5d40beff.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/5125675620f04dfb95c3a86b2048ce6e.png
[e106059c8f6343279fd6c93a72239813.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/ba0e209e3183412e9d96f4c0de49ceb0.png
[8dbae365fc1c4541b2d2b6e14125c9f9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/bd02091523f14bf2bb033e5a2abe1dae.png
[MQ_100_]: https://www.bilibili.com/video/BV1iv4y147ct/?spm_id_from=333.337.search-card.all.click&vd_source=a1af903e57688df870625021f7f3a7eb