rabbitmq集群功能讲解

 http://zhanghua.1199.blog.163.com/blog/static/4644980720138171451630/

看了很多关于rabbitmq集群的文章&＃xff0c;感觉官网写的太抽像&＃xff0c;并且个别地方如果不是elrong开发人员根本就了解不到&＃xff0c;通过各地方收集&＃xff0c;大致了解rabbitmq集群的二种方式&＃xff1a;

           普通模式&＃xff1a;默认的集群模式。

           镜像模式&＃xff1a;把需要的队列做成镜像队列。

网上关于这两种的介绍都很一样&＃xff0c;现在把它们记录在博客里&＃xff0c;并对细节加以修改。

-------------------------------------------------------------网络分割线-------------------------------------------

      RabbitMQ集群中节点包括内存节点、磁盘节点。内存节点就是将所有数据放在内存&＃xff0c;磁盘节点将数据放在磁盘上。如果在投递消息时&＃xff0c;打开了消息的持久化&＃xff0c;那么即使是内存节点&＃xff0c;数据还是安全的放在磁盘。

一个rabbitmq集群中可以共享 user&＃xff0c;vhost&＃xff0c;exchange等&＃xff0c;所有的数据和状态都是必须在所有节点上复制的&＃xff0c;对于queue根据集群模式不同&＃xff0c;应该有不同的表现。

普通模式&＃xff1a;默认的集群模式。

默认的集群模式&＃xff0c;queue创建之后&＃xff0c;如果没有其它policy&＃xff0c;则queue就会按照普通模式集群。对于Queue来说&＃xff0c;消息实体只存在于其中一个节点&＃xff0c;A、B两个节点仅有相同的元数据&＃xff0c;即队列结构&＃xff0c;但队列的元数据仅保存有一份&＃xff0c;即创建该队列的rabbitmq节点&＃xff08;A节点&＃xff09;&＃xff0c;当A节点宕机&＃xff0c;你可以去其B节点查看&＃xff0c;./rabbitmqctl list_queues 发现该队列已经丢失&＃xff0c;但声明的exchange还存在。

当消息进入A节点的Queue中后&＃xff0c;consumer从B节点拉取时&＃xff0c;RabbitMQ会临时在A、B间进行消息传输&＃xff0c;把A中的消息实体取出并经过B发送给consumer&＃xff0c;所以consumer应平均连接每一个节点&＃xff0c;从中取消息。

该模式存在一个问题就是当A节点故障后&＃xff0c;B节点无法取到A节点中还未消费的消息实体。

如果做了队列持久化或消息持久化&＃xff0c;那么得等A节点恢复&＃xff0c;然后才可被消费&＃xff0c;并且在A节点恢复之前其它节点不能再创建A节点已经创建过的持久队列&＃xff1b;如果没有持久化的话&＃xff0c;消息就会失丢。

这种模式更适合非持久化队列&＃xff0c;只有该队列是非持久的&＃xff0c;客户端才能重新连接到集群里的其他节点&＃xff0c;并重新创建队列。假如该队列是持久化的&＃xff0c;那么唯一办法是将故障节点恢复起来。

 为什么RabbitMQ不将队列复制到集群里每个节点呢&＃xff1f;这与它的集群的设计本意相冲突&＃xff0c;集群的设计目的就是增加更多节点时&＃xff0c;能线性的增加性能&＃xff08;CPU、内存&＃xff09;和容量&＃xff08;内存、磁盘&＃xff09;。理由如下

1. storage space: If every cluster node had a full copy of every queue, adding nodes wouldn’t give you more storage capacity. For example, if one node could store 1GB of messages, adding two more nodes would simply give you two more copies of the same 1GB of messages.

2. performance: Publishing messages would require replicating those messages to every cluster node. For durable messages that would require triggering disk activity on all nodes for every message. Your network and disk load would increase every time you added a node, keeping the performance of the cluster the same (or possibly worse).

     当然RabbitMQ新版本集群也支持队列复制&＃xff08;有个选项可以配置&＃xff09;。比如在有五个节点的集群里&＃xff0c;可以指定某个队列的内容在2个节点上进行存储&＃xff0c;从而在性能与高可用性之间取得一个平衡&＃xff08;应该就是指镜像模式&＃xff09;。

     镜像模式&＃xff1a;把需要的队列做成镜像队列&＃xff0c;存在于多个节点&＃xff0c;属于RabbitMQ的HA方案。

该模式解决了上述问题&＃xff0c;其实质和普通模式不同之处在于&＃xff0c;消息实体会主动在镜像节点间同步&＃xff0c;而不是在consumer取数据时临时拉取。

该模式带来的副作用也很明显&＃xff0c;除了降低系统性能外&＃xff0c;如果镜像队列数量过多&＃xff0c;加之大量的消息进入&＃xff0c;集群内部的网络带宽将会被这种同步通讯大大消耗掉。

所以在对可靠性要求较高的场合中适用&＃xff0c;一个队列想做成镜像队列&＃xff0c;需要先设置policy&＃xff0c;然后客户端创建队列的时候&＃xff0c;rabbitmq集群根据“队列名称”自动设置是普通集群模式或镜像队列。具体如下&＃xff1a;

队列通过策略来使能镜像。策略能在任何时刻改变&＃xff0c;rabbitmq队列也近可能的将队列随着策略变化而变化&＃xff1b;非镜像队列和镜像队列之间是有区别的&＃xff0c;前者缺乏额外的镜像基础设施&＃xff0c;没有任何slave&＃xff0c;因此会运行得更快。

为了使队列称为镜像队列&＃xff0c;你将会创建一个策略来匹配队列&＃xff0c;设置策略有两个键“ha-mode和 ha-params&＃xff08;可选&＃xff09;”。ha-params根据ha-mode设置不同的值&＃xff0c;下面表格说明这些key的选项

         需要注意的是设置和修改一个“nodes”策略将不会引起已经存在的master离开&＃xff0c;尽管你让其离开。比如&＃xff1a;如果一个队列在{A}&＃xff0c;并且你给它一个节点策略告知它在{B C}&＃xff0c;它将会在{A B C}。如果节点A那时失败或者停机了&＃xff0c;那个节点上的镜像将不回来且队列将继续保持在{B C}&＃xff08;注&＃xff1a;当队列已经是镜像队列且同步到其它节点&＃xff0c;就算原节点宕机&＃xff0c;也不影响其它节点对此队列使用&＃xff09;。

2、创建策略例子。

  队列名称以“ha.”开头的队列都是镜像队列&＃xff0c;镜像到集群内所有节点&＃xff1a;

 队列名称以“two.”开头的队列&＃xff0c;其策略镜像到集群内任何两个节点&＃xff1a;

   队列同步到指rabbitmq 节点  &＃xff0c;rabbitmqctl&＃xff1a;

./rabbitmqctl set_policy sa-specify "^sa\.specify\." &＃39;{"ha-mode":"nodes","ha-params":["rabbit&＃64;is137","rabbit&＃64;raxtone"]}&＃39;

切记&＃xff0c;需要把队列同步到的节点都写进去。
例子&＃xff0c;以下我们来创建几个例子&＃xff0c;验证上面讲的镜像队列。

首先&＃xff0c;我们目前的集群status:

接着我们创建一个&＃xff0c;nodes策略&＃xff0c;并且创建一个队列&＃xff0c;查看此队列的消息&＃xff1a;

 

我们关闭rabbit&＃64;is137节点&＃xff08;是disc节点&＃xff09;&＃xff0c;然后再查看节点和队列信息&＃xff0c;并且consumer此节点的数据&＃xff1a;

然后我们启动刚才关闭的节点&＃xff0c;删除策略&＃xff0c;再次查看队列信息&＃xff1a;

然后发现&＃xff0c;队列已经随着策略发生了改变&＃xff0c;没有slave_pids了&＃xff08;但一般策略我们定义了&＃xff0c;应该不会去改变&＃xff09;

参考于&＃xff1a;http://www.cnblogs.com/flat_peach/archive/2013/04/07/3004008.html