微服务高级篇（五）：可靠消息服务

文章目录

一、消息队列MQ存在的问题？
[二、如何保证 `消息可靠性` ？](#二、如何保证 消息可靠性 ？)
- [2.1 生产者消息确认【对生产者配置】](#2.1 生产者消息确认【对生产者配置】)
- [2.2 消息持久化](#2.2 消息持久化)
- [2.3 消费者消息确认【对消费者配置】](#2.3 消费者消息确认【对消费者配置】)
- [2.4 消费失败重试机制](#2.4 消费失败重试机制)
- [2.5 消费者失败消息处理策略](#2.5 消费者失败消息处理策略)
- [2.6 总结](#2.6 总结)
三、处理延迟消息？死信交换机
- [3.1 死信交换机概念](#3.1 死信交换机概念)
- [3.2 TTL](#3.2 TTL)
- [3.3 延迟队列 Delay Queue](#3.3 延迟队列 Delay Queue)
- - [3.3.1 安装DelayExchange插件](#3.3.1 安装DelayExchange插件)
  - [3.3.2 SpringAMQP使用延迟队列插件](#3.3.2 SpringAMQP使用延迟队列插件)
四、处理消息堆积问题？惰性队列
- [4.1 消息堆积问题](#4.1 消息堆积问题)
- [4.2 惰性队列 Lazy Queue](#4.2 惰性队列 Lazy Queue)
五、高可用性：MQ集群
- [5.1 集群分类](#5.1 集群分类)
- [5.2 普通集群](#5.2 普通集群)
- - [5.2.1 部署](#5.2.1 部署)
  - [5.2.2 获取cookie](#5.2.2 获取cookie)
  - [5.2.3 准备集群配置](#5.2.3 准备集群配置)
  - [5.2.4 启动集群](#5.2.4 启动集群)
  - [5.2.5 测试](#5.2.5 测试)
- [5.3 镜像集群](#5.3 镜像集群)
- - [5.3.1 镜像模式的特征](#5.3.1 镜像模式的特征)
  - [5.3.2 镜像模式的配置](#5.3.2 镜像模式的配置)
  - [5.3.3 测试](#5.3.3 测试)
- [5.4 仲裁队列](#5.4 仲裁队列)
- - [5.4.1 添加仲裁队列](#5.4.1 添加仲裁队列)
  - [5.4.2 测试](#5.4.2 测试)
  - [5.4.3 集群扩容](#5.4.3 集群扩容)
- [5.5 使用SpringAMQP创建仲裁队列](#5.5 使用SpringAMQP创建仲裁队列)

一、消息队列MQ存在的问题？

消息的可靠性问题：如何确保发送的消息至少被消费一次
延迟消息问题：如何实现消息的延迟投递
消息堆积问题：如何解决数百万消息堆积，无法及时消费的问题
高可用问题：如何避免单点的MQ故障而导致的不可用问题

二、如何保证 `消息可靠性` ？

2.1 生产者消息确认【对生产者配置】

演示：前提RabbitMQ有一个交换机amq.topic，队列simple.queue，并且二者绑定bind了rountingKey为simple.#

CommonConfig.java

java 复制代码

@Slf4j
@Configuration
public class CommonConfig implements ApplicationContextAware {

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        // 获取RabbitTemplate对象
        RabbitTemplate rabbitTemplate = applicationContext.getBean(RabbitTemplate.class);
        // 配置ReturnCallback
        rabbitTemplate.setReturnCallback((message, replyCode, replyText, exchange, routingKey) -> {
            // 判断是否是延迟消息
            Integer receivedDelay = message.getMessageProperties().getReceivedDelay();
            if (receivedDelay != null && receivedDelay > 0) {
                // 是一个延迟消息，忽略这个错误提示
                return;
            }
            // 记录日志
            log.error("消息发送到队列失败。响应码：{}, 失败原因：{}, 交换机: {}, 路由key：{}, 消息: {}",
                    replyCode, replyText, exchange, routingKey, message.toString());
            // 如果有需要的话，重发消息
        });
    }
}

测试类：

java 复制代码

    @Autowired
    private RabbitTemplate rabbitTemplate;

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

此时结果为：

java 复制代码

22:28:57:420 DEBUG 9600 --- [07.236.163:5672] cn.itcast.mq.spring.SpringAmqpTest       : 消息成功投递到交换机！消息ID: 06e7f233-d126-4c23-8499-547869e7a9b6

当rabbitTemplate.convertAndSend("aaaaamq.topic", "simple.test", message, correlationData);，此时结果为：

java 复制代码

22:42:30:013 ERROR 18652 --- [nectionFactory1] cn.itcast.mq.spring.SpringAmqpTest       : 消息投递到交换机失败！消息ID：4b3d6575-03bc-4473-a343-5c8ef30c6496

当rabbitTemplate.convertAndSend("amq.topic", "aaa.simple.test", message, correlationData);，此时结果为：

java 复制代码

22:28:57:420 DEBUG 9600 --- [07.236.163:5672] cn.itcast.mq.spring.SpringAmqpTest       : 消息成功投递到交换机！消息ID: 06e7f233-d126-4c23-8499-547869e7a9b6
22:28:57:424 ERROR 9600 --- [nectionFactory1] cn.itcast.mq.config.CommonConfig         : 消息发送到队列失败。响应码：312, 失败原因：NO_ROUTE, 交换机: amq.topic, 路由key：a.simple.test, 消息: (Body:'hello, spring amqp!' MessageProperties [headers={spring_returned_message_correlation=06e7f233-d126-4c23-8499-547869e7a9b6}, contentType=text/plain, contentEncoding=UTF-8, contentLength=0, receivedDeliveryMode=PERSISTENT, priority=0, deliveryTag=0])

2.2 消息持久化

当通过docker restart mq重启RabbitMQ发现，之前设置的队列都被清理了，因此需要做消息的持久化。

下面交换机与队列的持久化在消费者中进行配置，消息的持久化在生产者中配置：

其实Spring默认消息是持久化的，无需专门设置，所以按照之前的写法也行。

2.3 消费者消息确认【对消费者配置】

消费者也需要进行消息的确认，当无异常时，会发送ack回执；当有异常时，会发出nack回执，告诉生产者我这里有异常，你再发送一遍消息。

下面三种方式最常使用的时自动auto生成回执。

如果利用auto机制，消费者有异常时，会发出nack回执，告诉生产者我这里有异常，生产者会发送消息，再异常再发，导致压力倍增。下面一节将处理这个问题。

2.4 消费失败重试机制

演示：

2.5 消费者失败消息处理策略

上述消费者本地重试消息失败后，默认消息会被丢弃，其实还有其他方式。

最常用的是RepublisjMessageRecover：将失败消息给专门处理失败消息的交换机和队列，然后人工处理其消息

java 复制代码

/**
 * 处理异常消息的交换机和队列
 */
@Configuration
public class ErrorMessageConfig {

    // 处理异常消息的交换机
    @Bean
    public DirectExchange errorMessageExchange(){
        return new DirectExchange("error.direct");
    }

    // 处理异常消息的队列
    @Bean
    public Queue errorQueue(){
        return new Queue("error.queue");
    }

    // 交换机和队列的绑定
    @Bean
    public Binding errorMessageBinding(){
        return BindingBuilder.bind(errorQueue()).to(errorMessageExchange()).with("error");
    }

    // 消费者失败消息处理策略:
    // republishMessageRecoverer方式
    @Bean
    public MessageRecoverer republishMessageRecoverer(RabbitTemplate rabbitTemplate){
        return new RepublishMessageRecoverer(rabbitTemplate, "error.direct", "error");
    }
}

2.6 总结

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

开启生产者确认机制，确保生产者的消息能到达队列
开启持久化功能，确保消息未消费前在队列中不会丢失
开启消费者确认机制为auto，由spring确认消息处理成功后完成ack
开启消费者失败重试机制，并设置MessageRecoverer，多次重试失败后将消息投递到异常交换机，交由人工处理

三、处理延迟消息？死信交换机

3.1 死信交换机概念

死信交换机看似与上一节的失败交换机类似，但失败交换机是由消费者将失败消息投递给交换机，而死信交换机模式是由队列将消息投递给死信交换机。

3.2 TTL

TTL，也就是Time-To-Live。如果一个队列中的消息TTL结束仍未消费，则会变为死信，ttl超时分为两种情况:

1）消息所在的队列设置了存活时间

2）消息本身设置了存活时间

下面实现两个交换机队列：TTL交换机队列，死信交换机队列

1.在cunsumer中指定TTL交换机队列（超时时间为10秒），死信交换机队列

java 复制代码

@Configuration
public class TTLMessageConfig {

    // TTL交换机
    @Bean
    public DirectExchange ttlDirectExchange(){
        return new DirectExchange("ttl.direct");
    }

    // TTL队列
    @Bean
    public Queue ttlQueue(){
        return QueueBuilder
                .durable("ttl.queue")
                .ttl(10000)   // 队列的超时时间为10秒
                .deadLetterExchange("dl.direct") // 死信交换机
                .deadLetterRoutingKey("dl") // 死信交换机的rountingKey
                .build();
    }

    @Bean
    public Binding ttlBinding(){
        return BindingBuilder.bind(ttlQueue()).to(ttlDirectExchange()).with("ttl");
    }
}

java 复制代码

@Slf4j
@Component
public class SpringRabbitListener {
    /**
     * 指定死信交换机、队列、绑定rountingKey值
     * @param msg
     */
    @RabbitListener(bindings = @QueueBinding(
            value = @Queue(name = "dl.queue", durable = "true"),
            exchange = @Exchange(name = "dl.direct"),
            key = "dl"
    ))
    public void listenDlQueue(String msg) {
        log.info("消费者接收到了dl.queue的延迟消息");
    }
}

2.在publisher中编写测试类，发送一个超时时间为5秒的消息

java 复制代码

    /**
     * 演示死信交换机：
     * 发送一个TTL超时时间为5秒的消息
     */
    @Test
    public void testTTLMessage() {
        // 1.准备消息
        Message message = MessageBuilder
                .withBody("hello, ttl messsage".getBytes(StandardCharsets.UTF_8))
                .setDeliveryMode(MessageDeliveryMode.PERSISTENT)
                .setExpiration("5000")
                .build();
        // 2.发送消息
        rabbitTemplate.convertAndSend("ttl.direct", "ttl", message);
        // 3.记录日志
        log.info("消息已经成功发送！");
    }

3.启动消费者和生产者，发现生产者发送消息5秒后消费者才接受到，可以得出结论：取TTL队列和TTL消息中超时时间短的发送给死信交换机。

java 复制代码

生产者的日志：
10:38:55:766  INFO 13084 --- [           main] cn.itcast.mq.spring.SpringAmqpTest       : 消息已经成功发送！


消费者的日志：
10:39:00:807  INFO 14876 --- [ntContainer#0-1] c.i.mq.listener.SpringRabbitListener     : 消费者接收到了dl.queue的延迟消息

总结：

1.消息超时的两种方式是？

1）给队列设置ttl属性，进入队列后超过ttl时间的消息变为死信
2）给消息设置ttl属性，队列接收到消息超过ttl时间后变为死信
3）两者共存时，以时间短的ttl为准

2.如何实现发送一个消息20秒后消费者才收到消息？

1）给消息的目标队列指定死信交换机
2）消费者监听与死信交换机绑定的队列
3）发送消息时给消息设置ttl为20秒

3.3 延迟队列 Delay Queue

利用TTL结合死信交换机，我们实现了消息发出后，消费者延迟收到消息的效果。这种消息模式就称为延迟队列（Delay Queue）模式。

延迟队列的使用场景包括：

延迟发送短信
用户下单，如果用户在15 分钟内未支付，则自动取消
预约工作会议，20分钟后自动通知所有参会人员

3.3.1 安装DelayExchange插件

官方的安装指南地址为：https://blog.rabbitmq.com/posts/2015/04/scheduling-messages-with-rabbitmq

上述文档是基于linux原生安装RabbitMQ，然后安装插件。

因为我们之前是基于Docker安装RabbitMQ，所以下面我们会讲解基于Docker来安装RabbitMQ插件。

下载插件

RabbitMQ有一个官方的插件社区，地址为：https://www.rabbitmq.com/community-plugins.html

其中包含各种各样的插件，包括我们要使用的DelayExchange插件：

大家可以去对应的GitHub页面下载3.8.9版本的插件，地址为https://github.com/rabbitmq/rabbitmq-delayed-message-exchange/releases/tag/3.8.9这个对应RabbitMQ的3.8.5以上版本。

课前资料也提供了下载好的插件：rabbitmq_delayed_message_exchange-3.8.9-0199d11c.ez

上传插件

因为我们是基于Docker安装，所以需要先查看RabbitMQ的插件目录对应的数据卷。如果不是基于Docker的同学，请参考第一章部分，重新创建Docker容器。

我们之前设定的RabbitMQ的数据卷名称为mq-plugins，所以我们使用下面命令查看数据卷：

sh 复制代码

docker volume inspect mq-plugins

可以得到下面结果：

java 复制代码

[root@iZ2ze1r1nnqykr8zfme6cjZ tmp]# docker volume inspect mq-plugins
[
    {
        "CreatedAt": "2024-03-26T11:02:23+08:00",
        "Driver": "local",
        "Labels": null,
        "Mountpoint": "/var/lib/docker/volumes/mq-plugins/_data",
        "Name": "mq-plugins",
        "Options": null,
        "Scope": "local"
    }
]

接下来，将插件上传到这个目录即可：Mountpoint目录下

安装插件

最后就是安装了，需要进入MQ容器内部来执行安装。我的容器名为mq，所以执行下面命令：

sh 复制代码

docker exec -it mq bash

执行时，请将其中的 -it 后面的mq替换为你自己的容器名.

进入容器内部后，执行下面命令开启插件：

sh 复制代码

rabbitmq-plugins enable rabbitmq_delayed_message_exchange

结果如下：

sh 复制代码

Enabling plugins on node rabbit@mq1:
rabbitmq_delayed_message_exchange
The following plugins have been configured:
  rabbitmq_delayed_message_exchange
  rabbitmq_management
  rabbitmq_management_agent
  rabbitmq_prometheus
  rabbitmq_web_dispatch
Applying plugin configuration to rabbit@mq1...
The following plugins have been enabled:
  rabbitmq_delayed_message_exchange

started 1 plugins.

最后通过exit命令退出容器

使用插件

DelayExchange插件的原理是对官方原生的Exchange做了功能的升级:

将DelayExchange接受到的消息暂存在内存中(官方的Exchange是无法存储消息的)。
在DelayExchange中计时，超时后才投递消息到队列中

1）如何创建一个延迟交换机？

在RabbitMQ的管理平台声明一个DelayExchange:

2）如何发送一个延迟消息？

消息的延迟时间需要在发送消息的时候指定:

3.3.2 SpringAMQP使用延迟队列插件

演示：在消费者consumer声明延迟交换机，有两种方式：

然后在发布者publisher发送一个延迟消息，添加一个x-delay

测试发现报错，解释：理论上消息到达了交换机会立即将消息转发出去，而延迟交换机会将消息保存下来，等时间到后再转发消息，因此在等待的时间会返回给发布者一个未到达队列的错误。

java 复制代码

生产者的日志：
11:25:22:536  INFO 5756 --- [           main] cn.itcast.mq.spring.SpringAmqpTest       : 发送消息成功
11:25:22:552 ERROR 5756 --- [nectionFactory1] cn.itcast.mq.config.CommonConfig         : 消息发送到队列失败。响应码：312, 失败原因：NO_ROUTE, 交换机: delay.direct, 路由key：delay, 消息: (Body:'[B@5f1dfcce(byte[19])' MessageProperties [headers={spring_returned_message_correlation=c411ed18-e4ea-44e0-add9-0d867bbbf282}, contentType=application/octet-stream, contentLength=0, receivedDeliveryMode=PERSISTENT, priority=0, receivedDelay=5000, deliveryTag=0])

Process finished with exit code 0

消费者的日志：
11:25:27:556  INFO 2612 --- [ntContainer#2-1] c.i.mq.listener.SpringRabbitListener     : 消费者接收到了delay.queue的延迟消息

这里我们修改发布者的ReturnCallback，添加逻辑忽略延迟消息。

java 复制代码

@Slf4j
@Configuration
public class CommonConfig implements ApplicationContextAware {

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        // 获取RabbitTemplate对象
        RabbitTemplate rabbitTemplate = applicationContext.getBean(RabbitTemplate.class);
        // 配置ReturnCallback
        rabbitTemplate.setReturnCallback((message, replyCode, replyText, exchange, routingKey) -> {
            // 判断是否是延迟消息
            Integer receivedDelay = message.getMessageProperties().getReceivedDelay();
            if (receivedDelay != null && receivedDelay > 0) {
                // 是一个延迟消息，忽略这个错误提示
                return;
            }
            // 记录日志
            log.error("消息发送到队列失败。响应码：{}, 失败原因：{}, 交换机: {}, 路由key：{}, 消息: {}",
                    replyCode, replyText, exchange, routingKey, message.toString());
            // 如果有需要的话，重发消息
        });
    }
}

最后结果如下：

java 复制代码

生产者的日志：
[delegate=amqp://itcast@39.107.236.163:5672/, localPort= 55991]
11:19:50:778  INFO 18824 --- [           main] cn.itcast.mq.spring.SpringAmqpTest       : 发送消息成功


消费者的日志：
11:19:55:816  INFO 13184 --- [ntContainer#2-1] c.i.mq.listener.SpringRabbitListener     : 消费者接收到了delay.queue的延迟消息

四、处理消息堆积问题？惰性队列

4.1 消息堆积问题

当生产者发送消息的速度超过了消费者处理消息的速度，就会导致队列中的消息堆积，直到队列存储消息达到上限。最早接收到的消息，可能就会成为死信，会被丢弃，这就是消息堆积问题。

解决消息堆积有三种种思路:

增加更多消费者，提高消费速度
在消费者内开启线程池加快消息处理速度
扩大队列容积，提高堆积上限

4.2 惰性队列 Lazy Queue

从RabbitMQ的3.6.0版本开始，就增加了Lazy Queues的概念，也就是惰性队列。惰性队列的特征如下:

接收到消息后直接存入磁盘而非内存
消费者要消费消息时才会从磁盘中读取并加载到内存
支持数百万条的消息存储

设置一个队列为惰性队列的方法？

方法一：只需要在声明队列时，指定x-queue-mode属性为lazy即可。可以通过命令行将一个运行中的队列修改为惰性队列:

方法二：使用SpringAMQP声明惰性队列：

演示：定义两个队列，惰性队列和普通队列，分别发送一百万条消息，看内存和磁盘情况

java 复制代码

/**
 * 惰性队列
 */
@Configuration
public class LazyConfig {

    // 惰性队列
    @Bean
    public Queue lazyQueue() {
        return QueueBuilder.durable("lazy.queue")
                .lazy()
                .build();
    }

    // 普通队列
    @Bean
    public Queue normalQueue() {
        return QueueBuilder.durable("normal.queue")
                .build();
    }
}

惰性队列：消息全在磁盘中

java 复制代码

    /**
     * 演示惰性队列：
     * 发送一百万条消息
     */
    @Test
    public void testLazyQueue() throws InterruptedException {
        long b = System.nanoTime();
        for (int i = 0; i < 1000000; i++) {
            // 1.准备消息
            Message message = MessageBuilder
                    .withBody("hello, Spring".getBytes(StandardCharsets.UTF_8))
                    .setDeliveryMode(MessageDeliveryMode.NON_PERSISTENT)
                    .build();
            // 2.发送消息
            rabbitTemplate.convertAndSend("lazy.queue", message);
        }
        long e = System.nanoTime();
        System.out.println(e - b);
    }

普通队列：消息再磁盘和内存中

java 复制代码

    /**
     * 演示普通队列：
     * 发送一百万条消息
     */
    @Test
    public void testNormalQueue() throws InterruptedException {
        long b = System.nanoTime();
        for (int i = 0; i < 1000000; i++) {
            // 1.准备消息
            Message message = MessageBuilder
                    .withBody("hello, Spring".getBytes(StandardCharsets.UTF_8))
                    .setDeliveryMode(MessageDeliveryMode.NON_PERSISTENT)
                    .build();
            // 2.发送消息
            rabbitTemplate.convertAndSend("normal.queue", message);
        }
        long e = System.nanoTime();
        System.out.println(e - b);
    }

五、高可用性：MQ集群

5.1 集群分类

在RabbitMQ的官方文档中，讲述了两种集群的配置方式：

普通模式：普通模式集群不进行数据同步，每个MQ都有自己的队列、数据信息（其它元数据信息如交换机等会同步）。例如我们有2个MQ：mq1，和mq2，如果你的消息在mq1，而你连接到了mq2，那么mq2会去mq1拉取消息，然后返回给你。如果mq1宕机，消息就会丢失。
镜像模式：与普通模式不同，队列会在各个mq的镜像节点之间同步，因此你连接到任何一个镜像节点，均可获取到消息。而且如果一个节点宕机，并不会导致数据丢失。不过，这种方式增加了数据同步的带宽消耗。

5.2 普通集群

接下来，我们看看如何安装RabbitMQ的集群。

5.2.1 部署

我们先来看普通模式集群，我们的计划部署3节点的mq集群：记得云服务器要暴露15672、5672、8081-8083、8071-8073端口

主机名	控制台端口	amqp通信端口
mq1	8081 ---> 15672	8071 ---> 5672
mq2	8082 ---> 15672	8072 ---> 5672
mq3	8083 ---> 15672	8073 ---> 5672

集群中的节点标示默认都是：rabbit@[hostname]，因此以上三个节点的名称分别为：

rabbit@mq1
rabbit@mq2
rabbit@mq3

5.2.2 获取cookie

RabbitMQ底层依赖于Erlang，而Erlang虚拟机就是一个面向分布式的语言，默认就支持集群模式。集群模式中的每个RabbitMQ 节点使用 cookie 来确定它们是否被允许相互通信。

要使两个节点能够通信，它们必须具有相同的共享秘密，称为Erlang cookie。cookie 只是一串最多 255 个字符的字母数字字符。

每个集群节点必须具有相同的 cookie。实例之间也需要它来相互通信。

我们先在之前启动的mq容器中获取一个cookie值，作为集群的cookie。执行下面的命令：

sh 复制代码

docker exec -it mq cat /var/lib/rabbitmq/.erlang.cookie

可以看到cookie值如下：

sh 复制代码

JBIXBEJBTRPDPHPGGZJV

接下来，停止并删除当前的mq容器，我们重新搭建集群。

sh 复制代码

docker rm -f mq

# 清理数据卷
docker volume prune

5.2.3 准备集群配置

在/tmp目录新建一个配置文件 rabbitmq.conf：

sh 复制代码

cd /tmp
# 创建文件
touch rabbitmq.conf

文件内容如下：

nginx 复制代码

loopback_users.guest = false
listeners.tcp.default = 5672
cluster_formation.peer_discovery_backend = rabbit_peer_discovery_classic_config
cluster_formation.classic_config.nodes.1 = rabbit@mq1
cluster_formation.classic_config.nodes.2 = rabbit@mq2
cluster_formation.classic_config.nodes.3 = rabbit@mq3

再创建一个文件，记录cookie

sh 复制代码

cd /tmp
# 创建cookie文件
touch .erlang.cookie
# 写入cookie
echo "JBIXBEJBTRPDPHPGGZJV" > .erlang.cookie
# 修改cookie文件的权限
chmod 600 .erlang.cookie

准备三个目录,mq1、mq2、mq3：

sh 复制代码

cd /tmp
# 创建目录
mkdir mq1 mq2 mq3

然后拷贝rabbitmq.conf、cookie文件到mq1、mq2、mq3：

sh 复制代码

# 进入/tmp
cd /tmp
# 拷贝
cp rabbitmq.conf mq1
cp rabbitmq.conf mq2
cp rabbitmq.conf mq3
cp .erlang.cookie mq1
cp .erlang.cookie mq2
cp .erlang.cookie mq3

5.2.4 启动集群

创建一个网络：

sh 复制代码

docker network create mq-net

运行命令

sh 复制代码

docker run -d --net mq-net \
-v ${PWD}/mq1/rabbitmq.conf:/etc/rabbitmq/rabbitmq.conf \
-v ${PWD}/.erlang.cookie:/var/lib/rabbitmq/.erlang.cookie \
-e RABBITMQ_DEFAULT_USER=itcast \
-e RABBITMQ_DEFAULT_PASS=123321 \
--name mq1 \
--hostname mq1 \
-p 8071:5672 \
-p 8081:15672 \
rabbitmq:3.8-management

sh 复制代码

docker run -d --net mq-net \
-v ${PWD}/mq2/rabbitmq.conf:/etc/rabbitmq/rabbitmq.conf \
-v ${PWD}/.erlang.cookie:/var/lib/rabbitmq/.erlang.cookie \
-e RABBITMQ_DEFAULT_USER=itcast \
-e RABBITMQ_DEFAULT_PASS=123321 \
--name mq2 \
--hostname mq2 \
-p 8072:5672 \
-p 8082:15672 \
rabbitmq:3.8-management

sh 复制代码

docker run -d --net mq-net \
-v ${PWD}/mq3/rabbitmq.conf:/etc/rabbitmq/rabbitmq.conf \
-v ${PWD}/.erlang.cookie:/var/lib/rabbitmq/.erlang.cookie \
-e RABBITMQ_DEFAULT_USER=itcast \
-e RABBITMQ_DEFAULT_PASS=123321 \
--name mq3 \
--hostname mq3 \
-p 8073:5672 \
-p 8083:15672 \
rabbitmq:3.8-management

输入ip地址:8082，可以3个集群都能看到

5.2.5 测试

在mq1这个节点上添加一个队列：

如图，在mq2和mq3两个控制台也都能看到：

数据共享测试

点击这个队列，进入管理页面：

然后利用控制台发送一条消息到这个队列：

结果在mq2、mq3上都能看到这条消息：

可用性测试

我们让其中一台节点mq1宕机：

sh 复制代码

docker stop mq1

然后登录mq2或mq3的控制台，发现simple.queue也不可用了：

说明数据并没有拷贝到mq2和mq3。

5.3 镜像集群

在刚刚的案例中，一旦创建队列的主机宕机，队列就会不可用。不具备高可用能力。如果要解决这个问题，必须使用官方提供的镜像集群方案。

官方文档地址：https://www.rabbitmq.com/ha.html

5.3.1 镜像模式的特征

默认情况下，队列只保存在创建该队列的节点上。而镜像模式下，创建队列的节点被称为该队列的主节点 ，队列还会拷贝到集群中的其它节点，也叫做该队列的镜像节点。

但是，不同队列可以在集群中的任意节点上创建，因此不同队列的主节点可以不同。甚至，一个队列的主节点可能是另一个队列的镜像节点。

用户发送给队列的一切请求，例如发送消息、消息回执默认都会在主节点完成，如果是从节点接收到请求，也会路由到主节点去完成。镜像节点仅仅起到备份数据作用。

当主节点接收到消费者的ACK时，所有镜像都会删除节点中的数据。

总结如下：

镜像队列结构是一主多从（从就是镜像）
所有操作都是主节点完成，然后同步给镜像节点
主宕机后，镜像节点会替代成新的主（如果在主从同步完成前，主就已经宕机，可能出现数据丢失）
不具备负载均衡功能，因为所有操作都会有主节点完成（但是不同队列，其主节点可以不同，可以利用这个提高吞吐量）

5.3.2 镜像模式的配置

镜像模式的配置有3种模式：

ha-mode	ha-params	效果
准确模式exactly	队列的副本量count	集群中队列副本（主服务器和镜像服务器之和）的数量。count如果为1意味着单个副本：即队列主节点。count值为2表示2个副本：1个队列主和1个队列镜像。换句话说：count = 镜像数量 + 1。如果群集中的节点数少于count，则该队列将镜像到所有节点。如果有集群总数大于count+1，并且包含镜像的节点出现故障，则将在另一个节点上创建一个新的镜像。
all	(none)	队列在群集中的所有节点之间进行镜像。队列将镜像到任何新加入的节点。镜像到所有节点将对所有群集节点施加额外的压力，包括网络I / O，磁盘I / O和磁盘空间使用情况。推荐使用exactly，设置副本数为（N / 2 +1）。
nodes	node names	指定队列创建到哪些节点，如果指定的节点全部不存在，则会出现异常。如果指定的节点在集群中存在，但是暂时不可用，会创建节点到当前客户端连接到的节点。

这里我们以rabbitmqctl命令作为案例来讲解配置语法。

语法示例：

exactly模式

rabbitmqctl set_policy ha-two "^two." '{"ha-mode":"exactly","ha-params":2,"ha-sync-mode":"automatic"}'

rabbitmqctl set_policy：固定写法
ha-two：策略名称，自定义
"^two\."：匹配队列的正则表达式，符合命名规则的队列才生效，这里是任何以two.开头的队列名称
'{"ha-mode":"exactly","ha-params":2,"ha-sync-mode":"automatic"}': 策略内容
- "ha-mode":"exactly"：策略模式，此处是exactly模式，指定副本数量
- "ha-params":2：策略参数，这里是2，就是副本数量为2，1主1镜像
- "ha-sync-mode":"automatic"：同步策略，默认是manual，即新加入的镜像节点不会同步旧的消息。如果设置为automatic，则新加入的镜像节点会把主节点中所有消息都同步，会带来额外的网络开销

all模式

rabbitmqctl set_policy ha-all "^all." '{"ha-mode":"all"}'

ha-all：策略名称，自定义
"^all\."：匹配所有以all.开头的队列名
'{"ha-mode":"all"}'：策略内容
- "ha-mode":"all"：策略模式，此处是all模式，即所有节点都会称为镜像节点

nodes模式

rabbitmqctl set_policy ha-nodes "^nodes." '{"ha-mode":"nodes","ha-params":["rabbit@nodeA", "rabbit@nodeB"]}'

rabbitmqctl set_policy：固定写法
ha-nodes：策略名称，自定义
"^nodes\."：匹配队列的正则表达式，符合命名规则的队列才生效，这里是任何以nodes.开头的队列名称
'{"ha-mode":"nodes","ha-params":["rabbit@nodeA", "rabbit@nodeB"]}': 策略内容
- "ha-mode":"nodes"：策略模式，此处是nodes模式
- "ha-params":["rabbit@mq1", "rabbit@mq2"]：策略参数，这里指定副本所在节点名称

5.3.3 测试

我们使用exactly模式的镜像，因为集群节点数量为3，因此镜像数量就设置为2.

我们进入mq1运行下面的命令：表示只要是以two开头的队列会创建一个镜像

sh 复制代码

# 进入mq1容器的控制台
docker exec -it mq1 bash
# 执行exactly模式
rabbitmqctl set_policy ha-two "^two\." '{"ha-mode":"exactly","ha-params":2,"ha-sync-mode":"automatic"}'
# 退出容器
exit

可以看到策略已经部署上

下面，我们创建一个新的队列：two.queue

在任意一个mq控制台查看队列：

测试数据共享

给two.queue发送一条消息：

然后在mq1、mq2、mq3的任意控制台都可以查看消息：

测试高可用

现在，我们让two.queue的主节点mq1宕机：

sh 复制代码

docker stop mq1

查看集群状态：

查看队列状态：mq2成为了主节点，mq3成为了镜像节点

发现依然是健康的！并且其主节点切换到了rabbit@mq2上

5.4 仲裁队列

仲裁队列:仲裁队列是3.8版本以后才有的新功能，用来替代镜像队列，具备下列特征:

与镜像队列一样，都是主从模式，支持主从数据同步
使用非常简单，没有复杂的配置
主从同步基于Raft协议，强一致

5.4.1 添加仲裁队列

在任意控制台添加一个队列，一定要选择队列类型为Quorum类型。

在任意控制台查看队列：

可以看到，仲裁队列的 + 2字样。代表这个队列有2个镜像节点。

因为仲裁队列默认的镜像数为5。如果你的集群有7个节点，那么镜像数肯定是5；而我们集群只有3个节点，因此镜像数量就是3.

5.4.2 测试

可以参考对镜像集群的测试，效果是一样的。

5.4.3 集群扩容

加入集群

1）启动一个新的MQ容器：

sh 复制代码

docker run -d --net mq-net \
-v ${PWD}/.erlang.cookie:/var/lib/rabbitmq/.erlang.cookie \
-e RABBITMQ_DEFAULT_USER=itcast \
-e RABBITMQ_DEFAULT_PASS=123321 \
--name mq4 \
--hostname mq5 \
-p 8074:15672 \
-p 8084:15672 \
rabbitmq:3.8-management

2）进入容器控制台：

sh 复制代码

docker exec -it mq4 bash

3）停止mq进程

sh 复制代码

rabbitmqctl stop_app

4）重置RabbitMQ中的数据：

sh 复制代码

rabbitmqctl reset

5）加入mq1：

sh 复制代码

rabbitmqctl join_cluster rabbit@mq1

6）再次启动mq进程

sh 复制代码

rabbitmqctl start_app

增加仲裁队列副本

我们先查看下quorum.queue这个队列目前的副本情况，进入mq1容器：

sh 复制代码

docker exec -it mq1 bash

执行命令：

sh 复制代码

rabbitmq-queues quorum_status "quorum.queue"

结果：

现在，我们让mq4也加入进来：

sh 复制代码

rabbitmq-queues add_member "quorum.queue" "rabbit@mq4"

结果：

再次查看：

sh 复制代码

rabbitmq-queues quorum_status "quorum.queue"

查看控制台，发现quorum.queue的镜像数量也从原来的 +2 变成了 +3：

5.5 使用SpringAMQP创建仲裁队列

修改xml文件

声明仲裁队列

java 复制代码

/**
 * 仲裁队列
 */
@Configuration
public class QuorumConfig {

    @Bean
    public Queue quorumQueue() {
        return QueueBuilder.durable("quorum.queue2") // 持久化
                .quorum() // 仲裁队列
                .build();
    }
}

启动运行，发现队列创建成功

微服务高级篇（五）：可靠消息服务

文章目录

一、消息队列MQ存在的问题？

二、如何保证 消息可靠性 ？

2.1 生产者消息确认【对生产者配置】

2.2 消息持久化

2.3 消费者消息确认【对消费者配置】

2.4 消费失败重试机制

2.5 消费者失败消息处理策略

2.6 总结

三、处理延迟消息？死信交换机

3.1 死信交换机概念

3.2 TTL

3.3 延迟队列 Delay Queue

3.3.1 安装DelayExchange插件

3.3.2 SpringAMQP使用延迟队列插件

四、处理消息堆积问题？惰性队列

4.1 消息堆积问题

4.2 惰性队列 Lazy Queue

五、高可用性：MQ集群

5.1 集群分类

5.2 普通集群

5.2.1 部署

5.2.2 获取cookie

5.2.3 准备集群配置

5.2.4 启动集群

5.2.5 测试

5.3 镜像集群

5.3.1 镜像模式的特征

5.3.2 镜像模式的配置

5.3.3 测试

5.4 仲裁队列

5.4.1 添加仲裁队列

5.4.2 测试

5.4.3 集群扩容

5.5 使用SpringAMQP创建仲裁队列

二、如何保证 `消息可靠性` ？