HM-SpringCloud微服务系列12.1【消息可靠性】

HM-SpringCloud微服务系列12：服务异步通信RabbitMQ-高级篇

回顾一下MQ的消息发送流程：消息msg从生产者publisher发送到交换机exchange，再到队列queue，最后到消费者consumer

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

发送时丢失：
- 生产者发送的消息未送达exchange
- 消息到达exchange后未到达queue
MQ宕机，queue将消息丢失
consumer接收到消息后未消费就宕机

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

生产者确认机制
mq持久化
消费者确认机制
失败重试机制

下面通过案例来演示每一个步骤。首先导入课前资料提供的demo工程：

虚拟机MQ环境准备：

1. 生产者消息确认

1.1 publisher confirm机制

RabbitMQ提供了publisher confirm机制来避免消息发送到MQ过程中丢失。这种机制必须给每个消息指定一个唯一ID。消息发送到MQ以后，会返回一个结果给发送者，表示消息是否处理成功。返回结果有两种方式：

publisher-confirm，发送者确认
- 消息成功投递到交换机，返回ack
- 消息未投递到交换机，返回nack
publisher-return，发送者回执
- 消息投递到交换机了，但是没有路由到队列。返回ACK，及路由失败原因。

1.2 SpringAMQP实现生产者确认

1.2.1 修改配置

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

spring:
  rabbitmq:
    publisher-confirm-type: correlated # 异步回调模式
    publisher-returns: true
    template:
      mandatory: true

说明：

publish-confirm-type：开启publisher-confirm，这里支持两种类型：
- simple：同步等待confirm结果，直到超时
- correlated：异步回调，定义ConfirmCallback，MQ返回结果时会回调这个ConfirmCallback
publish-returns：开启publish-return功能，同样是基于callback机制，不过是定义ReturnCallback
template.mandatory：定义消息路由失败时的策略。true，则调用ReturnCallback；false：则直接丢弃消息

1.2.2 定义Return回调

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

修改publisher服务，添加一个配置类：

package cn.itcast.mq.config;

import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.core.Message;
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;

@Slf4j
@Configuration
public class CommonConfig implements ApplicationContextAware { // 实现Bean工厂通知

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        // 获取RabbitTemplate对象
        RabbitTemplate rabbitTemplate = applicationContext.getBean(RabbitTemplate.class);

        // 配置ReturnCallback（lambda表达式本质是匿名内部类。匿名内部类所实现接口中只有一个方法时可以用lambda替换）
        /*rabbitTemplate.setReturnCallback(new RabbitTemplate.ReturnCallback() {
            @Override
            public void returnedMessage(Message message, int replyCode, String replyText, String exchange, String routingKey) {

            }
        }); */
        rabbitTemplate.setReturnCallback((message, replyCode, replyText, exchange, routingKey) -> {
            // 消息投递失败，记录日志
            log.error("消息发送到队列失败，响应码：{}，失败原因：{}，交换机：{}，路由key：{}，消息：{}",
                    replyCode, replyText, exchange, routingKey, message.toString());
            // 如果有业务需要，可以在此之下重发消息
        });
    }
}

交换机与队列手动绑定：

之前课程学MQ时是这样发送消息的：

1.2.3 定义ConfirmCallback

ConfirmCallback可以在发送消息时指定，因为每个业务处理confirm成功或失败的逻辑不一定相同。

在publisher服务的cn.itcast.mq.spring.SpringAmqpTest类中，定义一个单元测试方法testSendMessage2SimpleQueue2()：

package cn.itcast.mq.spring;

import lombok.extern.slf4j.Slf4j;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.amqp.rabbit.connection.CorrelationData;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.junit4.SpringRunner;
import org.springframework.util.concurrent.FailureCallback;
import org.springframework.util.concurrent.SuccessCallback;

import java.util.UUID;

@Slf4j
@RunWith(SpringRunner.class)
@SpringBootTest
public class SpringAmqpTest {

    @Autowired
    private RabbitTemplate rabbitTemplate;

    @Test
    public void testSendMessage2SimpleQueue() throws InterruptedException {
        String routingKey = "simple.test";
        // 1. 准备消息
        String message = "hello, spring amqp!";
        // 2. 发送消息
        rabbitTemplate.convertAndSend("amq.topic", routingKey, message);
    }

    @Test
    public void testSendMessage2SimpleQueue2() throws InterruptedException {
        // 1. 准备消息
        String message = "hello, spring amqp!";

        // 2. 准备CorrelationData
        // 2.1 消息ID（全局唯一的消息ID，需要封装到CorrelationData中）
        CorrelationData correlationData = new CorrelationData(UUID.randomUUID().toString());

        // 2.2 准备ConfirmCallback
        /*correlationData.getFuture().addCallback(new SuccessCallback<CorrelationData.Confirm>() {
            @Override
            public void onSuccess(CorrelationData.Confirm result) {}
        }, new FailureCallback() {
            @Override
            public void onFailure(Throwable ex) {}
        });*/
        correlationData.getFuture().addCallback(result -> {
            // 判断结果
            if (result.isAck()) {
                //ACK:消息成功
                log.debug("消息成功投递到交换机！消息ID：{}", correlationData.getId());
            }else {
                //NACK:消息失败
                log.error("消息投递到交换机失败！消息ID：{}", correlationData.getId());
                // 如果有业务需要，可以在此之下重发消息
            }
        }, ex -> {
            // 消息投递失败，记录日志
            log.error("消息发送异常！", ex);
            // 如果有业务需要，可以在此之下重发消息
        });

        // 3. 发送消息
        rabbitTemplate.convertAndSend("amq.topic", "simple.test", message, correlationData);
//        rabbitTemplate.convertAndSend("aaaamq.topic", "simple.test", message, correlationData); //故意填错交换机模拟投递失败
//        rabbitTemplate.convertAndSend("amq.topic", "aaa.simple.test", message, correlationData); //故意填错路由模拟投递异常
    }
}

1.2.4 测试

成功情况：

失败情况1：

失败情况2：

1.3 小结

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

publisher-comfirm：
- 消息成功发送到exchange，返回ack
- 消息发送失败，没有到达交换机，返回nack
- 消息发送过程中出现异常，没有收到回执
消息成功发送到exchange，但没有路由到queue，调用ReturnCallback

2. 消息持久化

2.1 持久化机制

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

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

交换机持久化
队列持久化
消息持久化

非持久化情景演示：

接1.2.4最后结果查看

重启虚拟机docker中的mq服务

再来查看管理界面，发现系统的amq.topic交换机还在；但刚刚自己创建的sample.queue队列没了，那消息也随之没了

2.2 实现持久化

2.2.1 交换机持久化

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

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

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

2.2.2 队列持久化

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

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

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

启动consumer服务测试

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

停止consumer服务，手动发送消息测试

既然队列也已经持久化了，现在重启一下mq，看看是否消息还在

重启完成，发现交换机、队列还在，不过队列里的消息没了

说明消息未实现持久化

2.2.3 消息持久化

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

1：非持久化
2：持久化

用java代码指定：

@Test
public void testDurableMsg() {
    // 1. 准备消息
    Message message = MessageBuilder.withBody("hello spring".getBytes(StandardCharsets.UTF_8))
        .setDeliveryMode(MessageDeliveryMode.PERSISTENT) //NON_PERSISTENT是非持久
        .build();
    // 2. 发送消息
    rabbitTemplate.convertAndSend("simple.queue", message);
    log.debug("消息发送成功");
}

mode=2即为持久化

重启mq

刷新mq管理界面，可以看到消息还在，证明消息持久化了

2.2.4 实际上上面三者默认持久化（源码分析）

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

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

3. 消费者消息确认

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

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

设想这样的场景：

1）RabbitMQ投递消息给消费者
2）消费者获取消息后，返回ACK给RabbitMQ
3）RabbitMQ删除消息
4）消费者宕机，消息尚未处理

这样，消息就丢失了。因此消费者返回ACK的时机非常重要。

而SpringAMQP则允许配置三种确认模式：

manual：手动ack，需要在业务代码结束后，调用api发送ack。
auto：自动ack，由spring（AOP-环绕增强）监测listener代码是否出现异常，没有异常则返回ack；抛出异常则返回nack
none：关闭ack，MQ假定消费者获取消息后会成功处理，因此消息投递后立即被删除

由此可知：

none模式下，消息投递是不可靠的，可能丢失
auto模式类似事务机制，出现异常时返回nack，消息回滚到mq；没有异常，返回ack
manual：自己根据业务情况，判断什么时候该ack

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

3.1 演示none模式

修改consumer服务的application.yml文件

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

@RabbitListener(queues = "simple.queue")
public void listenSimpleQueue(String msg) {
    System.out.println("消费者接收到simple.queue的消息：【" + msg + "】");
    System.out.println(1/0); //模拟异常：手动错误
    log.info("消费者处理消息成功！");
}

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

当前，simple.queue中有两条消息

debug启动Consumer服务

启动成功立马进入了断点，然后现在查看mq管理页面发现simple.queue中消息没了

但可以看到，消费者这里还有消息；接着调试

可惜的是，抛异常了-->消费者没了，然后消息也丢失了

3.2 演示auto模式

修改consumer服务的application.yml文件，把确认机制修改为auto:

先在simple.queue中手动准备一条消息

在异常位置打断点，再次发送消息，程序卡在断点时，可以发现此时消息状态为unack（未确定状态）：

启动成功立刻进入断点，此时可以看到mq管理界面中显示消息状态由ready变为unacked

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

报错后，消息被重新投递了，并没有消失

4. 消费失败重试机制

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

怎么办呢？

4.1 本地重试

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

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

spring:
  rabbitmq:
    listener:
      simple:
        retry:
          enabled: true # 开启消费者失败重试
          initial-interval: 1000 # 初始的失败等待时长为1秒
          multiplier: 1 # 失败的等待时长倍数，下次等待时长 = multiplier * last-interval
          max-attempts: 3 # 最大重试次数
          stateless: true # true无状态（默认）；false有状态。如果业务中包含事务，这里改为false，不然会导致事务失效

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

在重试3次后，SpringAMQP会抛出异常AmqpRejectAndDontRequeueException，说明本地重试触发了
查看RabbitMQ控制台，发现消息被删除了，说明最后SpringAMQP返回的是ack，mq删除消息了

结论：

开启本地重试时，消息处理过程中抛出异常，不会requeue到队列，而是在消费者本地重试
重试达到最大次数后，Spring会返回ack，消息会被丢弃

4.2 失败策略RepublishMessageRecoverer

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

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

RejectAndDontRequeueRecoverer：重试耗尽后，直接reject，丢弃消息。默认就是这种方式
ImmediateRequeueMessageRecoverer：重试耗尽后，返回nack，消息重新入队
RepublishMessageRecoverer：重试耗尽后，将失败消息投递到指定的交换机

这种情况下第一种方案RejectAndDontRequeueRecoverer会直接将消息丢弃；而第二种方案ImmediateRequeueMessageRecoverer则会将消息重新塞入simple.queue。

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

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

4.2.2 定义一个RepublishMessageRecoverer关联队列和交换机

4.2.3 测试

完整代码

package cn.itcast.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 ErrorMsgConfig {

    /**
     * 异常消息交换机
     * @return
     */
    @Bean
    public DirectExchange errorMsgExchange() {
        return new DirectExchange("error.direct");
    }

    /**
     * 异常消息队列
     * @return
     */
    @Bean
    public Queue errorMsgQueue() {
        return new Queue("error.queue");
    }

    /**
     * 绑定队列&交换机
     * @return
     */
    @Bean
    public Binding errorMsgBinding() {
        // 利用BindingBuilder，先指定队列，再指定交换机，最后写路由key
        return BindingBuilder
                .bind(errorMsgQueue())
                .to(errorMsgExchange())
                .with("error");
    }

    /**
     * 关联队列&交换机
     * @return
     */
    @Bean
    public MessageRecoverer republishMsgRecover(RabbitTemplate rabbitTemplate) {
        return new RepublishMessageRecoverer(rabbitTemplate, "error.direct", "error");
        // 注意此处的交换机名字和路由key一定要与上面定义的一致
    }
}