镜像队列的配置通过添加policy完成，policy添加的命令为：
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，manually
Priority: 可选参数， policy的优先级
例如，对队列名称以hello开头的所有队列进行镜像，并在集群的两个节点上完成镜像，policy的设置命令为：
rabbitmqctl set_policy hello-ha "^hello" '{"ha-mode":"exactly","ha-params":2,"ha-sync-mode":"automatic"}'
2. 镜像队列的大概实现
(1) 整体介绍
通常队列由两部分组成：一部分是amqqueue_process，负责协议相关的消息处理，即接收生产者发布的消息、向消费者投递消息、处理消息confirm、acknowledge等等；另一部分是backing_queue，它提供了相关的接口供amqqueue_process调用，完成消息的存储以及可能的持久化工作等。
镜像队列同样由这两部分组成，amqqueue_process仍旧进行协议相关的消息处理，backing_queue则是由master节点和slave节点组成的一个特殊的backing_queue。master节点和slave节点都由一组进程组成，一个负责消息广播的gm，一个负责对gm收到的广播消息进行回调处理。在master节点上回调处理是coordinator，在slave节点上则是mirror_queue_slave。mirror_queue_slave中包含了普通的backing_queue进行消息的存储，master节点中backing_queue包含在mirror_queue_master中由amqqueue_process进行调用。
注意：消息的发布与消费都是通过master节点完成。master节点对消息进行处理的同时将消息的处理动作通过gm广播给所有的slave节点，slave节点的gm收到消息后，通过回调交由mirror_queue_slave进行实际的处理。
(2) gm(Guaranteed Multicast)
传统的主从复制方式：由master节点负责向所有slave节点发送需要复制的消息，在复制过程中，如果有slave节点出现异常，master节点需要作出相应的处理；如果是master节点本身出现问题，那么slave节点间可能会进行通信决定本次复制是否继续。当然为了处理各种异常情况，整个过程中的日志记录是免不了的。
然而rabbitmq中并没有采用这种方式，而是将所有的节点形成一个循环链表，每个节点都会监控位于自己左右两边的节点，当有节点新增时，相邻的节点保证当前广播的消息会复制到新的节点上；当有节点失效时，相邻的节点会接管保证本次广播的消息会复制到所有节点。
在master节点和slave节点上的这些gm形成一个group，group的信息会记录在mnesia中。不同的镜像队列形成不同的group。
消息从master节点对应的gm发出后，顺着链表依次传送到所有节点，由于所有节点组成一个循环链表，master节点对应的gm最终会收到自己发送的消息，这个时候master节点就知道消息已经复制到所有slave节点了。
(3) 重要的表结构
rabbit_queue表记录队列的相关信息：
引用
-record(amqqueue,
{
name, %%队列的名称
durable, %%标识队列是否持久化
auto_delete, %%标识队列是否自动删除
exclusive_owner, %%标识是否独占模式
arguments, %%队列创建时的参数
pid, %%amqqueue_process进程PID
slave_pids, %%mirror_queue_slave进程PID集合
sync_slave_pids, %%已同步的slave进程PID集合
policy, %%与队列有关的policy
%%通过set_policy设置,没有则为undefined
gm_pids, %%{gm,mirror_queue_coordinator},{gm,mirror_queue_slave}进程PID集合
decorator %%
}).
{
name, %%队列的名称
durable, %%标识队列是否持久化
auto_delete, %%标识队列是否自动删除
exclusive_owner, %%标识是否独占模式
arguments, %%队列创建时的参数
pid, %%amqqueue_process进程PID
slave_pids, %%mirror_queue_slave进程PID集合
sync_slave_pids, %%已同步的slave进程PID集合
policy, %%与队列有关的policy
%%通过set_policy设置,没有则为undefined
gm_pids, %%{gm,mirror_queue_coordinator},{gm,mirror_queue_slave}进程PID集合
decorator %%
}).
注意：slave_pids的存储是按照slave加入的时间来排序的，以便master节点失效时，提升"资格最老"的slave节点为新的master。
gm_group表记录gm形成的group的相关信息：
参考：https://my.oschina.net/hncscwc/blog/186350?p=1