【从零开始学习RabbitMQ | 第二篇】如何确保MQ的可靠性和消费者可靠性

前言：

MQ可靠性：

数据持久化：

[Lazy Queue：](#Lazy Queue：)

前言：

在上一篇文章中，我们介绍了如何确保生产者的可靠性，确保消息一定可以到达MQ。

【从零开始学习RabbitMQ | 第一篇】如何确保生产者的可靠性-CSDN博客https://liyuanxin.blog.csdn.net/article/details/139261125?spm=1001.2014.3001.5502

但是MQ自己也是会丢失消息的，比如MQ的突然宕机或者消息过多造成的阻塞，因此我们这篇文章来介绍一下如何确保MQ的可靠性和消费者可靠性

默认情况下，RabbitMQ会把接收到的消息保存在内存中来降低消息收发的延迟，但这样会导致两个问题：

一旦MQ宕机，内存中的消息会丢失
内存空间有限，当消费者故障或者处理过慢的时候，会导致消息的积压，引发阻塞。

想要保证MQ的可靠性，主要依赖于两种方式：

数据持久化
Lazy Queue

MQ可靠性：

数据持久化：

RabbitMQ实现持久化主要有三个部分：

持久化队列（Durable Queues）: 持久化队列指的是队列本身被存储在磁盘上，这样即使RabbitMQ服务器重启，队列也不会丢失。要创建持久化队列，需要在声明队列时设置durable属性为true。持久化队列中的消息默认不是持久化的，需要单独设置每条消息为持久化。
持久化消息（Persistent Messages）: 持久化消息意味着消息本身被存储在磁盘上，因此即使RabbitMQ服务器重启，消息也不会丢失。在发送消息时，需要设置消息的deliveryMode属性为2（即PERSISTENT），这样RabbitMQ就会将消息存储到磁盘上。
持久化交换机（Durable Exchanges）: 持久化交换器与持久化队列类似，指的是交换器被存储在磁盘上，这样服务器重启后交换器依然存在。声明交换器时，也需要设置durable属性为true。持久化交换器确保了消息路由的结构在服务器重启后能够保留。

当我们把消息持久化到磁盘中的时候，就避免了消息挤压造成的阻塞。但是当我们把消息持久化到磁盘中的时候，这个时候是不能接收新的消息的。

Lazy Queue：

因此实际上把消息持久化到磁盘中不是一个很好的解决方案，在RabbitMQ的3.6.0版本后，增加了Lazy Queue这个概念。其实就是懒惰队列：

懒惰队列的特性如下：

接收到消息后直接存入磁盘而不是内存（内存只保留最近的消息，默认2048条）。
消费者要消费消息的时候才会从磁盘中读取并加载到内存中。
支持数百万条的消息存储。

在3.12版本后，所有的队列都是Lazy Queue模式，无法更改。

消费者可靠性：

消费者确认机制：

为了确认消费者是否成功处理消息，RabbitMQ提供了消费者确认机制（Consumer Acknowledgement）。当消费者处理消息的结束之后，将会向RabbitMQ发送一个回执，告知自己消息的处理状态，消费者一共可以向Rabbitmq回执三种处理状态，分别是：

**ACK:**成功处理消息，RabbitMQ从队列中删除该消息
NACK:消息处理失败，RabbitMQ再次投递消息
REJECT: 消息处理失败并拒绝该消息，RabbitMQ从队列中删除该消息

而消费者确认机制并不用我们手写，Spring AMQP已经为我们实现了消费者消息确认机制，并允许我们通过配置文件的形式选择ACK处理方式，有三种：

none：不处理，消息投递给消费者之后就会ack，消息会从MQ中删除，不安全
manual：手动模式。需要自己调用api发送ack或者reject。
auto：托管给Spring AMQP 利用 AOP实现消费者确认机制。当业务正常执行的时候返回ack

当业务异常的时候，根据异常不同返回不同的结果：

如果是业务异常，自动返回nack
如果是消息处理或者校验异常，自动返回reject

Spring AMQP的消费者确认机制默认开启auto。

消费失败处理：

如果我们把消费者确认机制配置为auto的时候，当消费者出现异常之后，消息会不断的重新入队到队列，再重新发送给消费者。同样的消息再次引发异常，再次入队，再次发送给消费者。

这样会导致MQ的消息处理数量飙升，带来不必要的压力，因此除了把处理失败的消息重新进行处理之外，我们还应该有其他的处理方案。

我们可以利用Spring 的retry机制，在消费者出现异常的时候使用本地重试，而不是无限制的requeue到MQ队列中。

java 复制代码

    listener:
      simple:
        prefetch: 1
        retry:
          enabled: true #开启超时重试机制
          initial-interval: 1000ms #失败后的初始等待时间
          multiplier: 1 #失败后下次等待时长倍数，下次等待时长= Initial - interval * multiplier
          max-attempts: 3 #最大重试次数
          stateless: true #true无状态，false有状态，如果业务中包含事务，就改为fasle

当我们开启重试模式之后，如果重试次数耗尽并且消息依然失败，那么就需要有MessageRecoverer接口来处理，这个接口包含三种不同的实现：