rabbitmq——镜像队列 博客分类： rabbitmq

1. 镜像队列的设置

镜像队列的配置通过添加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         %%
}).

注意：slave_pids的存储是按照slave加入的时间来排序的，以便master节点失效时，提升"资格最老"的slave节点为新的master。

gm_group表记录gm形成的group的相关信息：

参考：https://my.oschina.net/hncscwc/blog/186350?p=1