RabbitMQ集群搭建与测试

由于项目工作的要求，需要用到RabbitMQ的集群相关的功能，所以就花时间去了解，测试了一下，暂时只是完成了第一步集群的搭建使用，以及集群的负载均衡管理，中间也绕过一些弯路，幸好这个东西玩过的人还是比较多了，而且它的社区也比较成熟了，所以可参考的资料还是挺丰富的，这个尝试完成之后，也想着把自己的一些尝试的过程记录一些，既是回顾其中的一些细节，也是给他人提供一个参考（若觉得靠谱的话，欢迎讨论）。

RabbitMQ的集群，这次我主要是在Windows环境下面搭建的，负载均衡的管理采用是的Windosw自带的NLB，相对比较方便，但是具体的项目测试还没有开始，仅是作为一个方案来考虑。

 

第一部分——RabbitMQ服务环境安装

服务器环境是两台WinServer2008x64的虚拟机，现在两台电脑上面各自完成RabbitMQ服务的搭建，大致的安装步骤如下：

从官方网站去下载相关的安装文件http://www.rabbitmq.com/install-windows.html，主要是：

a)        Python安装文件：python_win32_ensetup.msi.rar

b)        Erlang的安装文件（RabbitMQ是基于Erlang开发的）：otp_win32_R16B03-1.exe

c)        RabbitMQ安装文件：rabbitmq-server-3.2.4.exe

相关的安装步骤可以参考官网的，这里不再赘述，也可以参考几个博客：。

 

我本地测试两台服务器名字分别是：RBMQ-2/RBMQ-3，安装完成之后，RabbitMQ会默认创建一个节点/账户，节点的信息分别是rabbitmq@RBQM-2/ rabbitmq@RBQM-3，创建了一个admin/admin的账户。

确认完成上述两台服务的安装，就可以参考RabbitMQ官网上面关于集群一些内容来配置了（http://www.rabbitmq.com/clustering.html），官网的主要的还是在Linux系统下完成的操作，在Windows下的参考内容较少，不过操作内容上是差不多的，接下来我们就来进行RB集群的配置。

第二部分——集群的配置

         在搭建RB集群的时候，需要了解RB集群下，相比较单个节点的情况，主要在以下几方面有区别：

a)        Queue metadata（队列元数据）：记录队列的名称和相关属性（是否持久队列、空队列是否自动删除等）；

b)        Exchange metadata（交换规则元数据）：交换规则名称及相关属性；

c)        Binding metadata（绑定元数据）：一份登记消息路由关系的表记录；

d)        Vhost metadata（虚拟主机元数据）：

 

在RB集群中，每个节点都是有一份exchange的拷贝，同时Queue metadata也在每个节点中各有一份登记，但是Queue中的消息内容只存在于接收消息的节点上，如果该节点异常宕机，此时则无法从其他节点获得并路由消息。

         至于为什么是这样的设计，在《RabbitMQIn Action》书中的解释是：

a)        降低磁盘

b)        降低内存

赘述完RB集群的这几个特点，那么接下来就开始动手配置RB集群（http://www.rabbitmq.com/clustering.html）

RB的集群是依附于Erlang的集群来工作的,所以必须先构建起Erlang的集群景象。Erlang的集群中各节点是经由过程一个magic cookie来实现的,这个cookie存放在C:\Users\管理员用户\.erlang.cookie 中(像我的Roy用户安装的就是放在我的C:\Users\Roy\.erlang.cookie中), 另外在WINDOWS系统中，会在C:\windows目录下也有一个.erlang.cookie，两个是一样的，各个节点的这两个文件必须要保持一致。

确认两台服务器的RabbitMQ服务（以下简称RB）都已经开启，未启动则开启:

>        rabbitmqctl status

……

>        rabbitmq-server –detcached

……

 

RB启动后，在配置集群之前，可以先查看集群的情况，方便搭建之后对照：

>        rabbitmqctl cluster_status

 

下面开始集群的配置，将RBMQ-2加入到RBMQ-3的集群下面，具体配置如下：

在RBMQ-2机器上执行：

>        rabbitmqctl stop_app

>        rabbitmqctl join_cluster rabbit@rabbit3

>        rabbitmqctl start_app

然后在RBMQ-2/RBMQ-3分别查询集群配置的情况：

或者可以在web端控制台查看（把RB2关闭，开启RB3）：

 

至此，RB的集群服务已经完成了配置，接下来是进行集群消息的测试。

关于集群，有几点需要注意的，就是节点的类型设置：

a)        集群中至少要求有一个节点时disc类型的节点，这样关于集群的配置才是有效的；

b)        仅当集群中disc类型的节点处于运行状态时，此时对集群的相关配置的修改才是有效的，否则都是无效的；

c)        若运行中的集群disc类型的节点宕掉，此时其他的ram节点仍能够继续提供服务，但若此时所有ram节点都宕掉，则在disc节点未启动的情况下，ram类型节点无法启动，因为所有的配置都保存在disc类型的节点下面，启动时，需要从该类型节点读取对应的配置。

d)        RB集群中，节点之间的exchange是在各个节点都有一份的，但是消息队列queue只存在对应的接收节点上面，其他节点不存储，如果对应该节点宕掉，那么接收到的消息队列可能都会丢失。

第三部分——队列镜像配置

         在完成RB集群配置之后，在高可用性已经向前走了一步，在了解了RB集群的特点之后，我们知晓RB中Queue的消息只存在于对应的接收节点，这种情况当对应的存储消息的节点（或称主服务）异常宕机的情况下，就存在消息丢失的可能，怎么改善这种应用场景，RB为我们提供了镜像队列（Mirror Queue）的方式。（http://www.rabbitmq.com/ha.html）

         镜像队列的特点：

        

归纳后，主要有这么几点:

1、  镜像模式配置完成之后，会存在一个主队列和多个镜像队列（或称为热备队列，Slaves），主队列在收到消息后，会同步消息至当前所有的镜像，若主队列消息被处理删除之后，镜像队列的数据会同步删除；

2、  当主队列异常宕掉后，RB会提升镜像队列中、早作为镜像服务的队列为主队列，其他的继续为当前主队列的镜像队列。

 

 

镜像队列是通过RB的配置策略（policy）来实现的，

镜像队列提供了三种模式：

Ø  all：全部的节点队列都做镜像；

Ø  exactly：指定镜像队列的节点最高镜像数量；

Ø  nodes：只为指定具体节点配置镜像队列；

Pattern的内容是正则表达式，以截图中的 ‘^Q’为例，表示以Q开头的所有队列名称都有镜像，其他的队列不设置镜像。

 

第四部分——NLB，为RB配置负载均衡

搭建的步骤参考：

一步一步配置NLB

http://blog.csdn.net/haoxiaozigang1/article/details/12198679

一步一步配置NLB（续）之深入测试http://blog.csdn.net/haoxiaozigang1/article/details/12444963

 

 

第五部分——测试代码

参考了其他的文章

http://www.cnblogs.com/rollenholt/p/4098089.html

http://jingyan.baidu.com/article/e73e26c0c3841b24adb6a7b9.html

http://blog.csdn.net/haoxiaozigang1/article/details/12444963

 http://www.cnblogs.com/me-sa/archive/2012/11/15/rabbitmq_cluster_mirrored_queue.html