RabbitMQ的一些常见问题

一        消息可靠性

1.1        消息丢失的环节

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

1.2        消息可靠性 

        从上面列出的可能丢失消息的地方入手，防止消息丢失。

1.2.1        生产者消息确认

        RabbitMQ提供了publisher confirm机制来避免消息发送到MQ过程中丢失。消息发送到MQ以后，会返回一个结果给发送者，表示消息是否处理成功。结果有两种请求：

publisher-confirm，

•         发送者确认 消息成功投递到交换机，返回ack
•         消息未投递到交换机，返回nack

publisher-return，

•         发送者回执 消息投递到交换机了，但是没有路由到队列。返回ACK，及路由失败原因。

 1.2.1.1        代码整合

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        消息持久化

        经过1.2.1的下消息确认后，消息会到达队列，但是rabbitmq是基于内存存储的，当mq服务重启后，数据就会从内存中丢失，所以，消息持久化就是为了防止消息从内存中丢失。创建一些可以持久化的交换机和队列。

package com.dj.cloudDemo.publisher.config;

import org.springframework.amqp.core.*;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

/**
 * @author jingdj
 * @version 1.0
 * @date 2023/10/20 11:05 上午
 * @desc    用来配置交换机，队列
 *      持久化，mq重启消息不丢失，会保存在磁盘中
 *  todo 实际，我们随便创建一个交换机或者队列，内部代码会自动创建持久化，除非我们单独指定持久化为false
 *      并且消息，也在rabbitTemplate.convertAndSend的这个方法中也会自动做成持久化的消息
 */
@Configuration
public class PersistenceConfig {

    @Bean
    public DirectExchange persistenceExchange(){
            // 队列名
            // true，将这个交换机持久化
            // false，当这个交换机上的所有队列都被删除后，这个交换机也会被删除
//        return new DirectExchange("name");    内部代码创建的就是持久化的交换机，下面的队列也是这样
        return new DirectExchange("persistenceExchange", true, false);
    }

    @Bean
    public Queue persistenceQueue(){
        return QueueBuilder.durable("persistenceQueue").build();
    }

    @Bean
    public Binding persistenceBinding(DirectExchange persistenceExchange, Queue persistenceQueue){
        return BindingBuilder.bind(persistenceQueue)
                .to(persistenceExchange).with("persistenceRouting");
    }
}

1.2.3        消费者消息确认

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

1.         manual：手动ack，需要在业务代码结束后，调用api发送ack。
2.         auto：自动ack，由spring监测listener代码是否出现异常，没有异常则返回ack；抛出异常则返回nack；然后会自动连续不间断的再次投递给消费者消费，直至成功，控制台可能会一直报错。
3.         none：关闭ack，MQ假定消费者获取消息后会成功处理，因此消息投递后立即被删除，消费者消费失败，它也不会进行重试，消息就彻底丢掉了。

rabbitmq:
    listener:
      simple:
        prefetch: 1  # 让消费者每次在读取消息时，只能预取一个，而不是吧队列中的消息全部抢到自己呢边后在慢慢消费
        # none，关闭ack；投递给消费者后就会直接从mq将消息删除，不管消费这是否正常消费
#        manual，手动ack；
#        auto：自动ack；消费者消费失败时，会自动连续投递给消费者消费，会一直投递，直至消费成功
        acknowledge-mode: auto

        auto模式下，消息会从ready状态变成unacked的状态。 

1.2.4        消费失败重试机制

        因为上面的auto模式会对mq造成很大的资源浪费，并且，加入是我们的代码引起的报错，无论后续投递多少次，结果都是会失败，就没有意义，只会造成资源浪费。消息会不断requeue（重新入队）到队列，再重新发送给消费者，然后再次异常，再次requeue，无限循环，导致mq的消息处理飙升，带来不必要的压力。

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

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

1.          RejectAndDontRequeueRecoverer：重试耗尽后，直接reject，丢弃消息。默认就是这种方式。
2.         ImmediateRequeueMessageRecoverer：重试耗尽后，返回nack，消息重新入队，还会继续向队列去发送消息。         
3.         RepublishMessageRecoverer：重试耗尽后，将失败消息投递到指定的交换机，推荐这种。

        重试机制是从消费者将消息投递到新的交换机上。 

1.2.4.2        代码 

package com.dj.cloudDemo.consumer.config;

import org.springframework.amqp.core.*;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.amqp.rabbit.retry.ImmediateRequeueMessageRecoverer;
import org.springframework.amqp.rabbit.retry.MessageRecoverer;
import org.springframework.amqp.rabbit.retry.RejectAndDontRequeueRecoverer;
import org.springframework.amqp.rabbit.retry.RepublishMessageRecoverer;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

/**
 * @author jingdj
 * @version 1.0
 * @date 2023/10/20 2:51 下午
 * @desc
 */
@Configuration
public class ErrorExchangeQueueConfig {

    /**
     * 配置错误交换机，队列，及绑定关系
     *  这种创建方式，会自动在mq上创建对应的交换机和队列
     *
     * @return
     */
    @Bean
    public DirectExchange errorExchange() {
        return new DirectExchange("error.exchange");
    }

    @Bean
    public Queue errorQueue() {
        return QueueBuilder.durable("error.queue").build();
    }

    @Bean
    public Binding errorBinding() {
        return BindingBuilder.bind(errorQueue()).to(errorExchange()).with("error");
    }


    /**
     * 配置消费者失败重试超重试次数后的处理配置
     */
    @Bean
    public MessageRecoverer messageRecoverer(RabbitTemplate rabbitTemplate) {
        return new RepublishMessageRecoverer(rabbitTemplate, "error.exchange", "error");  //重试耗尽后，将失败消息投递到指定的交换机，推荐这种。
//        return new ImmediateRequeueMessageRecoverer();    //重试耗尽后，返回nack，消息重新入队，还会继续向队列去发送消息。
//        return new RejectAndDontRequeueRecoverer(); //重试耗尽后，直接reject，丢弃消息。默认就是这种方式。
    }
}

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

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

二        死信交换机

2.1        死信交换机

        当一个队列中的消息满足下列情况之一时，可以成为死信（dead letter）：

• 消费者使用basic.reject或 basic.nack声明消费失败，并且消息的requeue参数设置为false
• 消息是一个过期消息，超时无人消费
• 要投递的队列消息堆积满了，最早的消息可能成为死信

        如果该队列配置了dead-letter-exchange属性，指定了一个交换机，那么队列中的死信就会投递到这个交换机中，而这个交换机称为死信交换机（Dead Letter Exchange，简称DLX）。

        这个和上面的重试的流程图很像，但是重试的是从消费者发到另一个交换机的，死信交换机这种是从队列发送到另一个交换机上的。

2.2        TTl

        需要注意，有一个先注册到mq上的死信交换机，对应队列的过期时间是10秒，后续在代码中更改了这个过期时间，30秒，启动会出现下面这个提醒，就是因为mq上的过期时间还是10秒，继续发送消息，过期时间还是10秒过期，并不是30秒。

Channel shutdown: channel error; protocol method: #method<channel.close>(reply-code=406, reply-text=PRECONDITION_FAILED - inequivalent arg 'x-message-ttl' for queue 'ttl.queue' in vhost 'cloud_study': received '30000' but current is '10000', class-id=50, method-id=10)

2.2.1        TTl概念

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

•         消息所在的队列设置了存活时间
•         消息本身设置了存活时间

2.2.2        总结

消息超时的两种方式是？

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

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

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

2.3        基于插件实现延迟队列

2.3.1        延迟插件安装

Community Plugins — RabbitMQ可以去这个页面下载对应的版本

docker安装单节点的mq，要配置挂载目录，方便后面安装插件
docker run \
 -e RABBITMQ_DEFAULT_USER=itcast \
 -e RABBITMQ_DEFAULT_PASS=123321 \
 -v mq-plugins:/plugins \
 --name mq \
 --hostname mq1 \
 -p 15672:15672 \
 -p 5672:5672 \
 -d \
 rabbitmq:3.8-management



安装完成后，将之前下载的插件放到对应的mq-plugins下，然后进行容器中，启动插件
rabbitmq-plugins enable rabbitmq_delayed_message_exchange

2.3.2        代码整合

        有两种实现方式，基于注解和java配置实现，来回切换测试的时候注意因上一种测试方式导致留在mq中的交换机和队列缓存。

        需要注意，由于之前配置了callback，会拦截发送不到交换机或者队列的一些错误信息，而延迟插件就是延迟一定时间后才将消息发送的队列，所以就会触发之前的报错，需要在配置中添加判断，过滤掉这个异常。

package com.dj.cloudDemo.publisher.config;

import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.core.Message;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
import org.springframework.context.annotation.Configuration;

/**
 * @author jingdj
 * @version 1.0
 * @date 2023/10/20 10:01 上午
 * @desc
 */
@Configuration
@Slf4j
public class CommonConfig implements ApplicationContextAware {

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        RabbitTemplate rabbitTemplate = applicationContext.getBean(RabbitTemplate.class);
        rabbitTemplate.setReturnCallback(new RabbitTemplate.ReturnCallback() {
            @Override
            public void returnedMessage(Message message, int replyCode, String replyText, String exchange, String rountingKey) {

                // todo 延迟插件的原理也是在mq原有的三种交换机基础上进行的增强，
                // todo 较于之前的ttl，插件延迟是在消息发送的时候进行延迟，所以说消息并没有到达交换机上，所以这里的配置会报一个NO_ROUT的错误信息
                // todo 之前的ttl模式，是将消息发送到正常的交换机上之后，并且消息页路由到了对应的队列上，这个队列上又配置了一个死信交换机，是在这个队列上延迟一定时间后，
                // todo 在将消息转发到对应的死信交换机上，最后路由到消费的队列上
                if (message.getMessageProperties().getReceivedDelay() > 0){  //延迟插件会又一个这个delay的属性，是我们要延迟的时间
                    return;
                }

                log.info("消息发送失败了，错误原因：{}，响应码：{}，响应信息：{}，交换机：{}，rountingKey：{}",
                        message, replyCode, replyText, exchange, rountingKey);
                // 可以根据响应码判断是否进行重发
//                rabbitTemplate.convertAndSend(exchange, "availability.queue", message);
            }
        });
    }
}

        延迟消息的发送使用的不是setExpiration了，而是.setHeader("x-delay","10000")。

        消息发送代码：

@Test
    public void testPluginsDelayQueue(){
        Message message = MessageBuilder.withBody("hello plugins queue".getBytes(StandardCharsets.UTF_8))
                .setDeliveryMode(MessageDeliveryMode.PERSISTENT)
                .setHeader("x-delay","10000")
//                .setExpiration("10000") todo   基于延迟插件的需要用上面那种
                .build();
        rabbitTemplate.convertAndSend("delay.exchange", "delayKey", message);
        log.info("延迟插件的消息发送成功");
    }

2.3.2.1        基于注解的形式

 @RabbitListener(bindings = @QueueBinding(
            exchange = @Exchange(value = "delay.exchange", delayed = "true"),
            value = @Queue(value = "delay.queue", durable = "true"),
            key = "delayKey"
    ))
    public void listenerPluginsDelayQueue(String message) {
        log.info("插件形式实现延迟队列，接受到消息:{}", message);
    }

2.3.2.2        基于配置的方式

package com.dj.cloudDemo.consumer.config;

import org.springframework.amqp.core.*;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

/**
 * @author jingdj
 * @version 1.0
 * @date 2023/10/21 8:48 上午
 * @desc    基于java配置方式，只需要打开这个文件和listeren中的listenerPluginsDelayQueue2
 *          基于注解的，需要将这个文件注释，listenerPluginsDelayQueue2注释，然后打开listenerPluginsDelayQueue方法即可
 *           有启动问题，看下是不是之前配置过的这个交换机和队列的问题，可以删除交换机和队列后，重新启动
 */
@Configuration
public class DelayedPluginsConfig {

    @Bean
    public DirectExchange delayExchange() {
        return ExchangeBuilder
                .directExchange("delay.exchange")
                .delayed()          // 多了这个配置
                .durable(true)
                .build();
    }

    @Bean
    public Queue delayQueue() {
        return QueueBuilder
                .durable("delay.queue")
                .build();
    }

    @Bean
    public Binding delayBinding(){
        return BindingBuilder.bind(delayQueue())
                .to(delayExchange())
                .with("delayKey");
    }

}




对应的监听者
@RabbitListener(queues = "delay.queue")
    public void listenerPluginsDelayQueue2(String message) {
        log.info("插件形式实现延迟队列，接受到消息:{}", message);
    }

三        惰性队列

3.1        消息堆积问题

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

        解决方案：

1. 增加更多消费者，提高消费速度，也就是增加多个监听者，监听同一个队列。
2. 在消费者内开启线程池加快消息处理速度，也不能多开，线程数过多会导致CPU的上下文过于频繁，浪费CPU资源，可以在一些业务比较长的场景下可以多开几个线程，比较短的业务场景就不开或者少开。
3. 扩大队列容积，提高堆积上限，提升这个队列装载消息的能力。

3.2        惰性队列

3.2.1        惰性队列的定义

        在上面的解决方法中，前两个比较简单，第三个如果我们直接直接去增加容积，将会有更多的消息存进内存中，所以就引入了惰性队列。

        惰性队列的特征如下：

1. 接收到消息后直接存入磁盘而非内存
2. 消费者要消费消息时才会从磁盘中读取并加载到内存，较于普通队列要比较耗时，磁盘IO
3. 支持数百万条的消息存储，基于磁盘，存储上限高

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

rabbitmqctl set_policy Lazy "^lazy-queue$" '{"queue-mode":"lazy"}' --apply-to queues 

Lazy：名称。        ""正则表达式，符合这个条件的都会被后面这个命令赋值

queues：用于所有的队列。

3.2.2        代码整合

可基于注解或者配置方式实现

package com.dj.cloudDemo.consumer.config;

import org.springframework.amqp.core.Queue;
import org.springframework.amqp.core.QueueBuilder;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

/**
 * @author jingdj
 * @version 1.0
 * @date 2023/10/21 4:16 下午
 * @desc    可基于注解或者配置方式实现
 */
@Configuration
public class LazyConfig {

    @Bean
    public Queue lazyQueue(){
        return QueueBuilder.durable("lazy.queue1")
                .lazy()             // 只需要增加这一个属性
                .build();
    }

    @Bean
    public Queue normalQueue(){
        return QueueBuilder.durable("normal.queue1")
                .build();
    }
}




注解形式：
    /**
     * 惰性队列
     *  这个测试就不接受消息了，这里只是将惰性队列的第二种创建方式（较于配置文件的方式）写下
     *  ，吧下面的监听者注销掉，因为发送的消息很多，后续消息太多可以直接将队列删除
     *  .setDeliveryMode(MessageDeliveryMode.NON_PERSISTENT)    // 消息不持久化 或者这样设置消息
     *
     *  下面这个第二种不是上面说的创建方式
     * 第一种声明方式必须指定交换机（bindings）
     * 第二种不需要指定交换机（queuesToDeclare）
     */
//    @RabbitListener(bindings = @QueueBinding(
//            value = @Queue(value = "lazy.queue1", durable = "true"),
//            arguments = @Argument(name = "x-queue-mode", value = "lazy"),
//            exchange = @Exchange(value = "lazy.exchange")
//    ))
//    @RabbitListener(queuesToDeclare = @Queue(
//            value = "lazy.queue1",
//            durable = "true",
//            arguments = @Argument(name = "x-queue-mode", value = "lazy")
//    ))
//    public void listenerLazyQueue(String message) {
//        log.info("接受惰性队列发送的消息:{}", message);
//    }




消息发送：
/*
    测试惰性队列和普通队列发送消息时，在内存还是磁盘进行存储
     */
    @Test
    public void testLazyQueue(){
        for (int i = 0; i < 500000; i++) {
            Message message = MessageBuilder.withBody("hello lazy queue".getBytes(StandardCharsets.UTF_8))
                    .setDeliveryMode(MessageDeliveryMode.NON_PERSISTENT)    // 消息不持久化
                    .build();
            rabbitTemplate.convertAndSend("lazy.queue1", message);
        }
    }

    @Test
    public void testNormalQueue(){
        for (int i = 0; i < 500000; i++) {
            Message message = MessageBuilder.withBody("hello normal queue".getBytes(StandardCharsets.UTF_8))
                    .setDeliveryMode(MessageDeliveryMode.NON_PERSISTENT)
                    .build();
            rabbitTemplate.convertAndSend("normal.queue1", message);
        }
    }

新建一个lazy队列和正常队列，各自发送20万数据

这个是惰性队列方式，消息没有存储在内存中，都是直接paged out写出到磁盘了

这个是正常的队列，消息先放在内存中，到达一定的峰值后，再paged out写出到磁盘了

3.2.3        总结

消息堆积问题的解决方案？

• 队列上绑定多个消费者，提高消费速度
• 给消费者开启线程池，提高消费速度
• 使用惰性队列，可以再mq中保存更多消息

惰性队列的优点有哪些？

• 基于磁盘存储，消息上限高
• 没有间歇性的page-out，性能比较稳定，普通队列时间歇性的进行page-out

惰性队列的缺点有哪些？

• 基于磁盘存储，消息时效性会降低
• 性能受限于磁盘的IO 

四        MQ集群

4.1        集群分类

        RabbitMQ的是基于Erlang语言编写，而Erlang又是一个面向并发的语言，天然支持集群模式。RabbitMQ的集群有两种模式：

1. 普通集群：是一种分布式集群，将队列分散到集群的各个节点，从而提高整个集群的并发能力。一个节点挂了，那这个节点上队列的消息就会丢失。
2. 镜像集群：是一种主从集群，普通集群的基础上，添加了主从备份功能，提高集群的数据可用性。有主从了，一个节点宕机，备用节点可以提补上，但是镜像集群的主从数据同步不是很完善，可能会出现部分数据未同步而主节点就挂了，导致这部分数据丢失的现象。

        镜像集群虽然支持主从，但主从同步并不是强一致的，某些情况下可能有数据丢失的风险。因此在RabbitMQ的3.8版本以后，推出了新的功能：仲裁队列来代替镜像集群，底层采用Raft协议确保主从的数据一致性。

4.2        普通集群

4.2.1        定义

        普通集群，或者叫标准集群（classic cluster），具备下列特征：

• 会在集群的各个节点间共享部分数据，包括：交换机、队列元信息。不包含队列中的消息。可以看到另一个节点创建的交换机，队列及队列中的消息。
• 当访问集群某节点时，如果队列不在该节点，会从数据所在节点传递到当前节点并返回，会看到其他节点的队列中的消息
• 队列所在节点宕机，队列中的消息就会丢失，创建这个队列的节点宕机了，那么其他节点就无法获取这个队列的消息了。

        queue1是节点1创建的，节点2和3都能看着从这个节点创建的队列和消息；从节点2或者3使用queue1发送消息，其他节点也能看到这个消息。相当于是又转发到节点1上去创建的消息，重启节点1后，非持久化的消息会丢失。 

 4.2.2        环境搭建

建议拉取3.8之后的镜像，仲裁队列的最低支持版本

1.    拉取镜像
docker pull rabbitmq:3.8-management

2.    创建对应的目录
mkdir mq1 mq2 mq3


3.    创建容器
##主节点
docker run -d --hostname rabbitmq01 --name rabbitmqCluster01 -v ....(自己的目录)/mq1:/var/lib/rabbitmq -p 15675:15672 -p 5675:5672 -e RABBITMQ_ERLANG_COOKIE='rabbitmqCookie' rabbitmq:3.8-management

##子节点
docker run -d --hostname rabbitmq02 --name rabbitmqCluster02 -v ....(自己的目录)/mq1:/var/lib/rabbitmq -p 15673:15672 -p 5673:5672 -e RABBITMQ_ERLANG_COOKIE='rabbitmqCookie'  --link rabbitmqCluster01:rabbitmq01 rabbitmq:3.8-management


##子节点
docker run -d --hostname rabbitmq03 --name rabbitmqCluster03 -v ....(自己的目录)/mq1:/var/lib/rabbitmq -p 15674:15672 -p 5674:5672 -e RABBITMQ_ERLANG_COOKIE='rabbitmqCookie'  --link rabbitmqCluster01:rabbitmq01 --link rabbitmqCluster02:rabbitmq02  rabbitmq:3.8-management


-e 容器环境变量， RABBITMQ_ERLANG_COOKIE 是rabbitmq节点加入集群必须的认证手段
-link 使容器间可以通信


4.    尝试在浏览器访问这三个节点，这时候三个节点并未建立起连接，还需要进行下面的配置
启动后尝试访问web管理页面是否成功
访问，并使用默认的guest账号登录（username：guest，password：guest）


5.    更改配置信息，建立集群
5.1    使用docker exec进入主节点所在容器的主机

docker exec -it rabbitmqCluster01 /bin/bash
关闭rabbitmq应用，并重置节点数据，再重新启动应用
# 停止服务
rabbitmqctl stop_app
# 离开所在的集群
rabbitmqctl reset
# 启动服务
rabbitmqctl start_app
exit

5.2    进入子节点所在rabbitmq02主机
docker exec -it rabbitmqCluster02 /bin/bash
同样关闭应用，并重置节点数据，然后使用rabbitmqctl join_cluster指令加入主节点所在集群
# 停止服务
rabbitmqctl stop_app
# 离开所在的集群
rabbitmqctl reset
# 加入集群
rabbitmqctl join_cluster --ram rabbit@rabbitmq01
# 启动服务
rabbitmqctl start_app
exit

5.3    然后进另一个子节点的主机，如法炮制
docker exec -it rabbitmqCluster03 /bin/bash
# 停止服务
rabbitmqctl stop_app
# 离开所在的集群
rabbitmqctl reset
# 加入集群
rabbitmqctl join_cluster --ram rabbit@rabbitmq01
# 启动服务
rabbitmqctl start_app
exit


6.    查看集群信息
docker exec -it rabbitmqCluster03 /bin/bash
随便进入一个节点中，执行
rabbitmqctl cluster_status

4.3        镜像集群

4.3.1        定义

        镜像集群：本质是主从模式，所以只需要在普通集群基础上添加一个配置命令就行了。镜像集群具备下面的特征：

• 交换机、队列、队列中的消息会在各个mq的镜像节点之间同步备份。
• 创建队列的节点被称为该队列的主节点，备份到的其它节点叫做该队列的镜像节点。
• 一个队列的主节点可能是另一个队列的镜像节点
• 所有操作都是主节点完成，然后同步给镜像节点
• 主宕机后，镜像节点会替代成新的主

        使用起来和普通集群相似，就算我们配置第一种命令时设置的数量是2，01是主，分到02为镜像节点，这时03也是能看到消息，发送消息（还是转发到了01上去执行）的。镜像模式，多了一种备份操作，节点1挂了之后，由它所创建的队列在普通集群下会丢失，但是镜像模式，会有一定的容宰能力，因为它有02点在做备份。

 4.3.2        搭建

        进入普通节点中的任意一个容器中，根据自己需要的配置执行命令即可。有三种配置方式：

| 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*      | 指定队列创建到哪些节点，如果指定的节点全部不存在，则会出现异常。如果指定的节点在集群中存在，但是暂时不可用，会创建节点到当前客户端连接到的节点。 |

1.
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，则新加入的镜像节点会把主节点中所有消息都同步，会带来额外的网络开销


2.
rabbitmqctl set_policy ha-all "^all\." '{"ha-mode":"all"}'
剩下两个02，03节点都会成为镜像节点。相当于是吧上面1中的命令设置为"ha-params":3。


3.
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"]`：策略参数，这里指定副本所在节点名称

4.4        仲裁队列

4.4.1        定义

        仲裁队列：仲裁队列是3.8版本以后才有的新功能，用来替代镜像队列，创建一个仲裁队列，默认会实现镜像队列，它的count默认是5，总节点数为小于等于6，默认就是其他5个节点都是镜像。具备下列特征：

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

 

4.4.2        代码

spring:
    rabbit:
        addresses: 127.0.0.1:5676,127.0.0.1:5677,127.0.0.1:5678
        username: imagemq
        password: 123321
        virtual-host: /



//    @RabbitListener(bindings = @QueueBinding(
//            value = @Queue(name = "quorum.queue7771",
//                    //给队列设置参数 x-queue-type 值为 quorum 就可将队列变为仲裁队列
//                    arguments = @Argument(name = "x-queue-type", value = "quorum")),
//            exchange = @Exchange(name = "test.exchange", type = ExchangeTypes.DIRECT),
//            key = "quorum"
//    ))
//    public void listenerQuorumQueue(String msg) {
//        log.info("接收到 quorum.queue 消息：" + msg);
//    }