Rabbitmq集群介绍队列高可用（镜像队列）

rabbitmq有3种模式，但集群模式是2种。详细如下：

• 单一模式：即单机情况不做集群，就单独运行一个rabbitmq而已。
• 普通模式：默认模式，以两个节点（rabbit01、rabbit02）为例来进行说明。对于Queue来说，消息实体只存在于其中一个节点rabbit01（或者rabbit02），rabbit01和rabbit02两个节点仅有相同的元数据，即队列的结构。当消息进入rabbit01节点的Queue后，consumer从rabbit02节点消费时，RabbitMQ会临时在rabbit01、rabbit02间进行消息传输，把A中的消息实体取出并经过B发送给consumer。所以consumer应尽量连接每一个节点，从中取消息。即对于同一个逻辑队列，要在多个节点建立物理Queue。否则无论consumer连rabbit01或rabbit02，出口总在rabbit01，会产生瓶颈。当rabbit01节点故障后，rabbit02节点无法取到rabbit01节点中还未消费的消息实体。如果做了消息持久化，那么得等rabbit01节点恢复，然后才可被消费；如果没有持久化的话，就会产生消息丢失的现象。
• 镜像模式:把需要的队列做成镜像队列，存在与多个节点属于RabbitMQ的HA方案。该模式解决了普通模式中的问题，其实质和普通模式不同之处在于，消息实体会主动在镜像节点间同步，而不是在客户端取数据时临时拉取。该模式带来的副作用也很明显，除了降低系统性能外，如果镜像队列数量过多，加之大量的消息进入，集群内部的网络带宽将会被这种同步通讯大大消耗掉。所以在对可靠性要求较高的场合中适用。

场景

集群环境下(节点A、B、C)，节点A宕机(QueueA所属节点)，客户端在剩余节点上声明持久化队列QueueA（非镜像队列），服务端响应404 NOT_FOUND。
注意：消费者客户端收到404报错后，默认自动关闭，需编写监听器重连或重启应用恢复。

解决方案

1. 恢复节点A，消费者客户端所在应用重启。（这是杀手锏）
2. 声明QueueA为高可用镜像队列。

镜像队列

默认情况下，rabbitmq 集群中的队列内容是仅在集群中的一个节点上的，也就是创建该队列的节点上。

如果该队列所在节点 down 了，那么这个队列中的内容就会丢失。

这种尴尬的情况下，镜像队列就应运而生了。

镜像队列机制，能够将当前节点的队列镜像到集群中的其他节点上，并且当前节点队列内容的有关操作，都会广播给其他节点。

所有对镜像队列主拷贝的操作，都会通过GM同步到各个slave节点，Coodinator负责组播结果的确认。GM是一种可靠的组播通信协议，该协议能够保证组播消息的原子性，即保证组内的存活节点要么都收到消息要么都收不到。

检查镜像队列是否生效

1 2 3

$ rabbitmqctl list_queues name policy pid slave_pids -p test-vhost Listing queues ... test.alarm.queue <rabbit@tesh-node1.1.318.0>

这里我们指定了 vhost。

命令结果来看，队列现在只在 node1 上，并没有镜像队列产生。

设置镜像队列

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

设置完成后，再次查询队列是否镜像了，仍然没有生效。

是否对已经存在的队列不生效，新建的队列才可以？

又新建队列进行测试，镜像仍然未生效。

 rabbitmq 不同 vhost 直接的配置是互相隔离的，需要不同的设置才可以。

经过长时间的尝试，发现设置镜像队列时，需要指定 vhost，否则默认只对 / 下的队列生效。

指定 vhost 设置镜像队列

1	rabbitmqctl set_policy ha-all "^test." '{"ha-mode":"all"}' -p test-vhost

设置后，对已有的队列是立即生效的。

 

用命令再查看

1 2 3

$ rabbitmqctl list_queues name policy pid slave_pids -p test-vhost Listing queues ... test.alarm.queue ha-all <rabbit@tesh-node1.1.318.0> [<rabbit@tesh-node2.1.30326.58>, <rabbit@tesh-node3.2.373.0>]

同样可以看出镜像队列已生效。