首页天道酬勤rabbitmq消费者集群,rabbitmq集群模式

rabbitmq消费者集群,rabbitmq集群模式

张世龙 05-12 08:04 13次浏览

根据项目的工作要求,需要使用RabbitMQ的集群相关功能,所以花了时间进行了调查和测试。 暂时只是完成了第一步集群的构建使用和集群的负载均衡管理,中途绕了远路。 好在这个玩过的人很多,而且这个社区也很成熟,所以可以参考的资料很丰富。 这个尝试完成后,我想记录自己的尝试过程

RabbitMQ的集群,这次我主要是在Windows环境下构建的。 是的,使用了Windosw附带的NLB来管理负载平衡。 虽然比较方便,但是具体的项目测试还没有开始,只是作为一个方案来考虑。

第一部分——RabbitMQ服务环境安装服务器环境是两台WinServer2008x64虚拟机,目前在两台计算机上分别完成RabbitMQ服务的构建,大致安装步骤如下:

要从官方网站下载相关安装文件http://www.rabbit MQ.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默认创建节点/帐户。 节点的信息分别为rabbit MQ @ rbqm-2/rabbit MQ @ rbqm-3,创建了admin/admin

查看上述两个服务的安装,可以参考有关集群的一些内容将其放置在RabbitMQ官方网站上。 (http://www.rabbit MQ.com/clustering.html ) )官方网站的主要内容是在Linux系统上操作,在Windows上引用的内容很少,但操作内容大致相同

第二部分——集群的配置

构建RB集群时,需要比较RB集群下各个节点的状况。 主要在以下方面有差异。

a ) Queue metadata ) )队列元数据)队列的名称和相关属性)记录是否为永久队列、空队列是否自动删除等);

b )交换元数据交换规则元数据(交换规则名称和相关属性;

c )注册绑定元数据(绑定元数据)消息路由关系的表记录

d )虚拟主机元数据:

在RB群集中,每个节点都有一个exchange副本,Queue metadata也在每个节点上注册一个,但Queue中的消息内容只存在于接收消息的节点上,如果该节点异常宕机,则在该点

为什么是这样的设计,在《RabbitMQIn Action》书中的说明是:

a )撤盘

b )降低内存

在介绍完RB集群的这些特征后,接下来开始配置RB集群(http://www.rabbit MQ.com/clustering.html )

因为RB的集群依赖于Erlang的集群进行动作,所以必须首先构建Erlang的集群像。 Erlang群集中的每个节点都通过一个幻像cookie进程实现。 此cookie存储在C:\Users\管理员用户\.erlang.cookie中(C:\windows目录中也有. erlang.cookie )。 两个是一样的。各个节点的这两个文件必须要保持一致

确认两台服务器的r

abbitMQ服务(以下简称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

rabbitmq两台机器集群,rabbitmq脱离集群