镜像队列

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

 

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的消息将会丢失。

 

关于镜像队列，我的理解是这样的：

1、首先，镜像队列是建立在集群基础之上的。它产生的背景是，队列位于单个结点上的，万一某个结点不可用，则整个集群变得不可用。镜像队列的出现就是要保证即使某个结点失败了，不影响，依然可以提供服务。

2、通过策略决定集群中的哪些结点被镜像化，也就是说，并不是集群中的所有结点都会被做成镜像

3、客户端向被镜像化的队列中发布消息以后，消息会被复制到其它镜像上

4、每个镜像队列由一个master和多个slave组成。slave失败了不要紧。master失败了会自动有slave成为新的master。

5、一般选取集群中结点个数的法定人数个结点做一个镜像队列

6、我觉得，镜像队列是凌驾于被做成镜像的那些队列之上的

 

 

参考 http://www.rabbitmq.com/ha.html