1、导入Demo工程

2、生产者消息确认

消息从发送，到消费者接收，会经历多个过程：

其中的每一步都可能导致消息丢失，常见的丢失原因包括：

针对这些问题，RabbitMQ分别给出了解决方案：

本篇博客就来带大家解决消息的可靠性。

1、导入Demo工程

导入Demo课程。

https://gitee.com/boring-yingjie/rabbit-mq-message-confirmation.git

把配置文件application.yml配置修改完毕。

然后我们在consumer 的config包的通用配置类创建一个队列。

运行consumer的启动类。

2、生产者消息确认

生产者确认机制：

注：

2.1 修改配置

首先，修改publisher服务中的application.yml文件，添加下面的内容：

spring:
  rabbitmq:
    publisher-confirm-type: correlated
    publisher-returns: true
    template:
      mandatory: true

配置说明：

2.2 定义Return回调

每个RabbitTemplate只能配置一个ReturnCallback，因此需要在项目加载时配置

修改publisher服务，添加一个：

package com.jie.mq.config;

import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.amqp.support.converter.Jackson2JsonMessageConverter;
import org.springframework.amqp.support.converter.MessageConverter;
import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
/**
 * @description:生产者通用配置
 * @author: jie
 * @time: 2022/2/25 15:34
 */
@Slf4j
@Configuration
public class CommonConfig implements ApplicationContextAware {
    /**
     * @description:每个RabbitTemplate只能配置一个ReturnCallback，因此需要在项目加载时配置
     * @author: jie 
     * @time: 2022/2/25 15:35
     */
    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        // 获取RabbitTemplate
        RabbitTemplate rabbitTemplate = applicationContext.getBean(RabbitTemplate.class);
        // 设置ReturnCallback
        rabbitTemplate.setReturnCallback((message, replyCode, replyText, exchange, routingKey) -> {
            // 投递失败，记录日志
            log.info("消息发送到队列失败，响应码{}，失败原因{}，交换机{}，路由键{},消息{}",
                    replyCode, replyText, exchange, routingKey, message.toString());
            // 如果有业务需要，可以重发消息
        });
    }
}

2.3 发送消息

我们发送消息通过一个单元测试来发。

这里面有一个最简单的消息发送代码。

我们要去为amq.topic这个交换机绑定一下simple.queue这个队列。这里我用的是手动的方式，大家可以选择使用代码的方式。

打开浏览器

点击进去

绑定完成，回到代码区，我现在发送消息，符合要求，那一定能发送成功，所以我们要修改一下代码。

	@Test
    public void testSendMessage2SimpleQueue() throws InterruptedException {
        String routingKey = "simple.test";
        //1、准备消息
        String message = "hello, spring amqp!";
        //2、准备CorrelationData
        //2.1 消息ID
        CorrelationData correlationData = new CorrelationData(UUID.randomUUID().toString());
        //2.2 准备ConfirmCallback
        //成功回调
        correlationData.getFuture().addCallback(confirm -> {
            //判断结果
            if(confirm.isAck()){
                //ACK 消息成功
                log.error("消息成功投递到交换机！消息ID：{}",correlationData.getId());
            }else {
                //NACK 消息失败
                log.error("消息投递到交换机失败！消息ID：{}",correlationData.getId());
                //重发消息
            }
            //失败回调
        }, throwable -> {
            //记录日志
            log.error("消息发送失败！",throwable);
        });
        //3、发送消息
        rabbitTemplate.convertAndSend("amq.topic", routingKey, message,correlationData);
    }

我们可以先运行代码查看控制消息。

这个是成功的情况，接下来演示一下失败的情况。比如消息根本没有到达交换机，可能是交换机名称填错了。

还有一种就是交换机到达了，没有到达队列。比如队列的名称填错了。

2.4 小结

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

3、消息持久化

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

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

3.1 交换机持久化

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

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

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

启动服务。

3.2 队列持久化

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

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

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

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

3.3 消息持久化

用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);
    }

3.4 小结

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

4、消费者消息确认

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

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

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

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

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

由此可知：

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文件，添加内容：

  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接口来处理，它包含三种不同的实现：

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

在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发送消息。