在RabbitMQ中，一个节点的服务其实也是作为一个集群来处理的，在web控制台的admin-> cluster 中可以看到集群的名字，并且可以在页面上修改。而多节点的集群有两种方式：

默认的普通集群模式

这种模式使用Erlang语言天生具备的集群方式搭建。这种集群模式下，集群的各个节点之间只会有相同的元数据，即队列结构，而消息不会进行冗余，只存在一个节点中。
消费时，如果消费的不是存有数据的节点， RabbitMQ会临时在节点之间进行数据传输，将消息从存有数据的节点传输到消费的节点。很显然，这种集群模式的消息可靠性不是很高。因为如果其中有个节点服务宕机了，那这个节点上的数据就无法消费了，需要等到这个节点服务恢复后才能消费，而这时，消费者端已经消费过的消息就有可能给不了服务端正确应答，服务起来后，就会再次消费这些消息，造成这部分消息重复消费。
另外，如果消息没有做持久化，重启就消息就会丢失。并且，这种集群模式也不支持高可用，即当某一个节点服务挂了后，需要手动重启服务，才能保证这一部分消息能正常消费。所以这种集群模式只适合一些对消息安全性不是很高的场景。
而在使用这种模式时，消费者应该尽量的连接上每一个节点，减少消息在集群中的传输

镜像模式

这种模式是在普通集群模式基础上的一种增强方案，这也就是RabbitMQ的官方HA高可用方案。需要在搭建了普通集群之后再补充搭建。其本质区别在于，这种模式会在镜像节点中间主动进行消息同步，而不是在客户端拉取消息时临时同步。
并且在集群内部有一个算法会选举产生master和slave，当一个master挂了后，也会自动选出一个来。从而给整个集群提供高可用能力。这种模式的消息可靠性更高，因为每个节点上都存着全量的消息。而他的弊端也
是明显的，集群内部的网络带宽会被这种同步通讯大量的消耗，进而降低整个集群的性能。这种模式下，队列数量最好不要过多。

实际开发环境可以通过，增加keepalived保证每个RabbitMQ的稳定性，当某一个节点上的RabbitMQ服务崩溃时，可以及时重新启动起来。另外，也可以增加HA-proxy来做前端的负载均衡，通过HA-proxy增加一个前端转发的虚
拟节点，应用可以像使用一个单点服务一样使用一个RabbitMQ集群

Rabbitmq 镜像队列设置

可以通过命令行的形式设置，也可以通过代码配置

1：指定全部节点进行镜像队列

    @Beanpublic Queue minorQueue() {Mapargs = new HashMap<>(2);//1,全部节点进行镜像队列args.put("x-ha-policy","all");return new Queue(RabbitConstant.MINOR_QUEUE,true,false,false,args);}

2： 指定节点进行镜像队列

@Beanpublic Queue minorQueue() {Mapargs = new HashMap<>(2);//2、指定节点进行镜像队列：args.put("x-ha-policy","nodes");args.put("x-ha-node","[rabbit@node01]");return new Queue(RabbitConstant.MINOR_QUEUE,true,false,false,args);}