如果RabbitMQ集群只有一个broker节点，那么该节点的失效将导致整个服务临时性的不可用，并且可能会导致message的丢失（尤其是在非持久化message存储于非持久化queue中的时候）。可以将所有message都设置为持久化，并且使用持久化的queue，但是这样仍然无法避免由于缓存导致的问题：因为message在发送之后和被写入磁盘并执行fsync之间存在一个虽然短暂但是会产生问题的时间窗。通过publisher的confirm机制能够确保客户端知道哪些message已经存入磁盘，尽管如此，一般不希望遇到因单点故障导致服务不可用。
如果RabbitMQ集群是由多个broker节点构成的，那么从服务的整体可用性上来讲，该集群对于单点失效是有弹性的，但是同时也需要注意：尽管exchange和binding能够在单点失效问题上幸免于难，但是queue和其上持有的message却不行，这是因为queue及其内容仅仅存储于单个节点之上，所以一个节点的失效表现为其对应的queue不可用。
举例说明一下，如果一个MQ集群由三个节点组成(MQ集群节点的模式也是有讲究的，一般三个节点会有一个RAM，两个DISK)，exchange、bindings 等元数据会在三个节点之间同步，但queue上的消息是不会同步的，且不特殊设置的情况下，Queue只会在一个节点存在。可能有的同学会提另一个问题，我从三个MQ几点的监控面板，都可以看到这个Queue？这个是对的，这是由于Queue的元数据也是在三个节点之间同步，但Queue的实际存储只会在一个节点。我们发送消息到指定Queue，其实是发送消息到指定节点下的Queue。如下图所示，消息发送至队列testQueue，无论发送者通过哪个MQ节点执行发送，其最终的执行都会是在MQ03节点执行消息的存储。
说到这儿，可能有的小伙伴就要问了？说好的，RabbitMQ集群提供高可用性呢。
分析一下，RabbitMQ集群搭建完成后，如果不进行任何高可用配置，会有哪些问题呢？
单点故障会导致消息丢失：如果MQ03节点故障，那么MQ03 中的消息就会丢失
无法最大化的利用MQ提供，提升执行效率：既然每次发送到队列testQueue的消息都会在MQ03节点存储，那么何必搭建集群。
引入RabbitMQ的镜像队列机制，将queue镜像到cluster中其他的节点之上。在该实现下，如果集群中的一个节点失效了，queue能自动地切换到镜像中的另一个节点以保证服务的可用性。在通常的用法中，针对每一个镜像队列都包含一个master和多个slave，分别对应于不同的节点。slave会准确地按照master执行命令的顺序进行命令执行，故slave与master上维护的状态应该是相同的。除了publish外所有动作都只会向master发送，然后由master将命令执行的结果广播给slave们，故看似从镜像队列中的消费操作实际上是在master上执行的。
一旦完成了选中的slave被提升为master的动作，发送到镜像队列的message将不会再丢失：publish到镜像队列的所有消息总是被直接publish到master和所有的slave之上。这样一旦master失效了，message仍然可以继续发送到其他slave上。
简单来说，镜像队列机制就是将队列在三个节点之间设置主从关系，消息会在三个节点之间进行自动同步，且如果其中一个节点不可用，并不会导致消息丢失或服务不可用的情况，提升MQ集群的整体高可用性。
先来看下设置镜像队列后的效果： 镜像队列会出现+2标识。
1.设置队列为镜像队列：How
两种方式：
通过监控面板设置
通过命令设置
rabbitmqctl set_policy [-p Vhost] Name Pattern Definition [Priority] -p Vhost： 可选参数，针对指定vhost下的queue进行设置 Name: policy的名称 Pattern: queue的匹配模式(正则表达式) Definition：镜像定义，包括三个部分ha-mode, ha-params, ha-sync-mode ha-mode:指明镜像队列的模式，有效值为 all/exactly/nodes all：表示在集群中所有的节点上进行镜像 exactly：表示在指定个数的节点上进行镜像，节点的个数由ha-params指定 nodes：表示在指定的节点上进行镜像，节点名称通过ha-params指定 ha-params：ha-mode模式需要用到的参数 ha-sync-mode：进行队列中消息的同步方式，有效值为automatic和manual priority：可选参数，policy的优先级