Highly Available (Mirrored) Queues
默认情况下，RabbitMQ集群中的队列都是位于单个结点上的。这一点和exchanges、bindings是不同的，因为这些是位于所有结点之上的。可以在多个结点之间将队列镜像化。每一个被镜像化的队列由一个master和一个或多个镜像组成，当master挂掉以后，最老的镜像将会成为新的master。
发布到队列上的消息会被复制到所有镜像上。消费者都连接到master上。在master上被确认的消息会从镜像中删除。队列镜像提供了可用性。
all participating nodes each do all the work（每个结点都要做所有的工作，也就是说，每个操作所有结点都要做一遍）
这种解决方案需要一个RabbitMQ集群。不推荐在WAN（广域网）上建立集群。
在分布式系统中有很多名词用来标识第一和第二副本。通常，典型的做法是用“master”表示队列的主副本，用“mirror”表示第二副本。然而，你会发现也有用“slave”来表示第二副本的。这是因为RabbitMQ CLI工具的历史原因造成的。
How Mirroring is Configured
镜像参数用策略来配置。一个策略通过正则表达式按名称匹配一个或多个队列。
Queue Arguments that Control Mirroring
策略可以在任何时候改变。创建一个非镜像的队列，然后在随后的某个时间点将它镜像化，这是有效的（反之亦然）。
一个非镜像队列和一个镜像队列是不同的，前者没有额外的镜像基础设施，并且可能提供更高的输出。
为了让队列变成镜像，你需要创建一个策略来匹配它们，并且设置策略key值ha-mode和（可选的）ha-params
下面表格列出了这些选项的具体含义：
| ha-mode | ha-params | Result |
| all | 集群中所有结点都被做成镜像 | |
| exactly | count |
集群中队列实例的数量。count值为1意味着只有master，没有mirrors，这种情况下如果master不可用，那么队列将不可用。count值为2意味着有一个master和一个mirror，此时，如果master不可用，则mirror会自动成为master。NumberOfQueueMirrors = NumberOfNodes - 1 |
| nodes | node names | 根据指定结点的名称来镜像 |
To How Many Nodes to Mirror?
镜像到所有队列是最保守的情况，大多数情况下你不必这么做。对于超过3结点的集群来说推荐镜像到结点的法定人数。比如：在3个结点的集群中选2个结点，在5个结点的集群中选3个结点。
Queue Master Location
所有队列的操作都会首先经过master，然后再复制到mirrors。保证消息的先进先出非常有必要。
Mirrored Queue Implementation and Semantics
每个镜像队列都有一个master和一个或多个mirrors，它们都分布在不同的节点上。mirrors应用发生在master上的操作，并且以和master上相同的顺序应用这些操作，因此维护它们之间有相同的状态。除了发布以为的其它操作都到master，master广播这个操作的影响给mirrors。因此，客户端从一个镜像队列那里消费实际上是从master那里消费。
如果master失败的话，运行得最久的那个mirror会成为master，因为运行得最久的那个最有可能和master是完全同步的。如果没有mirror和master是同步的，那么那些只存在于master的消息将会丢失。
参考 http://www.rabbitmq.com/ha.html