RabbitMQ中的消息可靠性问题（下）

2023-06-09 88

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

容器服务 Serverless 版 ACK Serverless，952元额度多规格

容器服务 Serverless 版 ACK Serverless，317元额度多规格

简介： RabbitMQ中的消息可靠性问题（下）

2.4 小结

SpringAMQP中处理消息确认的几种情况：

publisher-comfirm：消息成功发送到exchange，返回Ack。消息发送失败，没有到达交换机，返回Nack。消息发送过程中出现异常，没有收到回执。

消息成功发送到exchange，但没有路由到queue
调用ReturnCallback。

3、消息持久化

生产者确认可以确保消息投递到RabbitMQ的队列中，但是消息发送到RabbitMQ以后，如果突然宕机，也可能导致消息丢失。

要想确保消息在RabbitMQ中安全保存，必须开启消息持久化机制。

交换机持久化

队列持久化

消息持久化

3.1 交换机持久化

RabbitMQ中交换机默认是非持久化的，mq重启后就丢失。

SpringAMQP中可以通过代码指定交换机持久化：

@Bean
public DirectExchange simpleExchange(){
    // 三个参数：交换机名称、是否持久化、当没有queue与其绑定时是否自动删除
    return new DirectExchange("simple.direct", true, false);
}

启动服务。

注：

事实上，默认情况下，由SpringAMQP声明的交换机都是持久化的。

3.2 队列持久化

RabbitMQ中队列默认是非持久化的，mq重启后就丢失。

SpringAMQP中可以通过代码指定交换机持久化：

@Bean
public Queue simpleQueue(){
    // 使用QueueBuilder构建队列，durable就是持久化的
    return QueueBuilder.durable("simple.queue").build();
}

注：

事实上，默认情况下，由SpringAMQP声明的队列都是持久化的。

可以在RabbitMQ控制台看到持久化的队列都会带上D的标示：

3.3 消息持久化

利用SpringAMQP发送消息时，可以设置消息的属性（MessageProperties），指定delivery-mode：

1：非持久化

2：持久化

用java代码指定：

@Test
    public void testDurableMessage() {
        //准备消息
        Message message = MessageBuilder.withBody("hell,spring".getBytes(StandardCharsets.UTF_8))
                .setDeliveryMode(MessageDeliveryMode.PERSISTENT)
                .build();
        // 2.发送消息
        rabbitTemplate.convertAndSend("simple.queue",message);
    }

注：默认情况下，SpringAMQP发出的任何消息都是持久化的，不用特意指定。

3.4 小结

默认情况下，由SpringAMQP声明的交换机和队列还有发出的消息都是默认持久化的。

4、消费者消息确认

RabbitMQ是阅后即焚机制，RabbitMQ确认消息被消费者消费后会立刻删除。

而RabbitMQ是通过消费者回执来确认消费者是否成功处理消息的：消费者获取消息后，应该向RabbitMQ发送ACK回执，表明自己已经处理消息。

生产者消息确认可以确保消息投递到队列当中，而消息的持久化可以保证不会因为MQ的宕机而导致消息的丢失，经过这两个我们可以保证消息能投递到消费者。

但是这个消费者是不是一定能消费这个消息呢？如果消息投递到消费者的那一刻，消费者挂了，那这样消息还是没有消费，消息就丢失了。

RabbitMQ支持消费者确认机制，即：消费者处理消息后可以向MQ发送Ack回执，MQ收到Ack回执后才会删除该消息。而SpringAMQP则允许配置三种确认模式：

manual：手动ack，需要在业务代码结束后，调用api发送ack。

auto：自动ack，由spring监测listener代码是否出现异常，没有异常则返回ack；抛出异常则返回nack。

none：关闭ack，MQ假定消费者获取消息后会成功处理，因此消息投递后立即被删除。

由此可知：

none模式下，消息投递是不可靠的，可能丢失。

auto模式类似事务机制，出现异常时返回nack，消息回滚到mq；没有异常，返回ack。

manual：自己根据业务情况，判断什么时候该ack。

一般，我们都是使用默认的auto即可。

4.1.演示none模式

修改consumer服务的application.yml文件，添加下面内容：

spring:
  rabbitmq:
    listener:
      simple:
        acknowledge-mode: none # 关闭ack

我们在这个队列先发留有一条消息。

修改consumer服务的SpringRabbitListener类中的方法，模拟一个消息处理异常：

我们打个断点用 Debug运行。再回到浏览器查看，发现消息已经没了。

我们回到代码区往下执行。

测试可以发现，当消息处理抛异常时，消息依然被RabbitMQ删除了。

4.2.演示auto模式

再次把确认机制修改为auto:

然后我们再往队列发送一条消息。

再次用Debug运行程序。

可以发现此时消息状态为unacked（未确定状态）。这什么意思呢？就是我还没收到Ack,我在等着你给我发呢，所以消息还没有删除。

抛出异常后，因为Spring会自动返回nack，所以消息恢复至Ready状态，并且没有被RabbitMQ删除。

如果我们把断点去掉，就会发生一个恐怖的事情，它就会进去一个死循环，它发现你投递失败了，又给你重新投递，一直重复这个操作。

这个显然也不太好，但是最起码消息不会丢失。

5、消费失败重试机制

当消费者出现异常后，消息会不断requeue（重入队）到队列，再重新发送给消费者，然后再次异常，再次requeue，无限循环，导致mq的消息处理飙升，带来不必要的压力：

5.1 本地重试

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

修改consumer服务的application.yml文件，添加内容：

yaml

复制代码

  retry:    enabled:true# 开启消费者失败重试    initial-interval:1000# 初识的失败等待时长为1秒    multiplier:1# 失败的等待时长倍数，下次等待时长 = multiplier * initial-interval    max-attempts:3# 最大重试次数，事不过三    stateless:true# true无状态；false有状态。如果业务中包含事务，这里改为false

重启consumer服务，重复之前的测试。可以发现：

在重试3次后，SpringAMQP会抛出异常，说明本地重试触发了。

查看RabbitMQ控制台，发现消息被删除了，说明最后SpringAMQP返回的是ack，mq删除消息了

5.2.失败策略

在之前的测试中，达到最大重试次数后，消息会被丢弃，这是由Spring内部机制决定的。

在开启重试模式后，重试次数耗尽，如果消息依然失败，则需要有MessageRecovery接口来处理，它包含三种不同的实现：

RejectAndDontRequeueRecoverer：重试耗尽后，直接reject，丢弃消息。默认就是这种方式。

ImmediateRequeueMessageRecoverer：重试耗尽后，返回nack，消息重新入队。

RepublishMessageRecoverer：重试耗尽后，将失败消息投递到指定的交换机。

比较好的一种处理方案是RepublishMessageRecoverer，失败后将消息投递到一个指定的，专门存放异常消息的队列，后续由人工集中处理。

1、在consumer服务中定义处理失败消息的交换机和队列

package com.jie.mq.config;
import org.springframework.amqp.core.Binding;
import org.springframework.amqp.core.BindingBuilder;
import org.springframework.amqp.core.DirectExchange;
import org.springframework.amqp.core.Queue;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.amqp.rabbit.retry.MessageRecoverer;
import org.springframework.amqp.rabbit.retry.RepublishMessageRecoverer;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
@Configuration
public class ErrorMessageConfig {
    /**
     * @description:异常消息交换机
     * @author: jie
     * @time: 2022/2/26 18:39
     */
    @Bean
    public DirectExchange errorMessageExchange() {
        return new DirectExchange("error.direct");
    }
    /**
     * @description:队列
     * @author: jie
     * @time: 2022/2/26 18:39
     */
    @Bean
    public Queue errorQueue(){
        return new Queue("err.queue");
    }
    /**
     * @description:将交换机和队列绑定
     * @author: jie
     * @time: 2022/2/26 18:39
     */
    @Bean
    public Binding errorMessageBinding(){
        return BindingBuilder
                .bind(errorQueue())
                .to(errorMessageExchange())
                .with("error");
    }
    /**
     * @description:异常消息处理器
     * @author: jie
     * @time: 2022/2/26 18:41
     */
    @Bean
    public MessageRecoverer republishMessageReciverer(RabbitTemplate rabbitTemplate){
        return new RepublishMessageRecoverer(rabbitTemplate,"error.direct","error");
    }
}

重新启动后我们向simple.queue发送消息。

6、总结

如何确保RabbitMQ消息的可靠性？

开启生产者确认机制，确保生产者的消息能到达队列。

开启持久化功能，确保消息未消费前在队列中不会丢失。

开启消费者确认机制为auto，由spring确认消息处理成功后完成ack。

开启消费者失败重试机制，并设置MessageRecoverer，多次重试失败后将消息投递到异常交换机，交由人工处理。

7、项目工程

gitee.com/boring-ying…