葵花宝典之消息中间件—RabbitMQ（搭建篇)

摘要：实际生产应用中都会采用消息队列的集群方案，若是选择RabbitMQ那么有必要了解下它的集群方案原理

通常来讲，若是只是为了学习RabbitMQ或者验证业务工程的正确性那么在本地环境或者测试环境上使用其单实例部署就能够了，可是出于MQ中间件自己的可靠性、并发性、吞吐量和消息堆积能力等问题的考虑，在生产环境上通常都会考虑使用RabbitMQ的集群方案。

对于RabbitMQ这么成熟的消息队列产品来讲，搭建它并不难而且也有很多童鞋写过如何搭建RabbitMQ消息队列集群的博文，但可能仍然有童鞋并不了解其背后的原理，这会致使其遇到性能问题时没法对集群进行进一步的调优。本篇主要介绍RabbitMQ集群方案的原理，如何搭建具有负载均衡能力的中小规模RabbitMQ集群，并最后给出生产环境构建一个可以具有高可用、高可靠和高吞吐量的中小规模RabbitMQ集群设计方案。

1、RabbitMQ集群方案的原理 RabbitMQ这款消息队列中间件产品自己是基于Erlang编写，Erlang语言天生具有分布式特性（经过同步Erlang集群各节点的magic cookie来实现）。所以，RabbitMQ自然支持Clustering。这使得RabbitMQ自己不须要像ActiveMQ、Kafka那样经过ZooKeeper分别来实现HA方案和保存集群的元数据。集群是保证可靠性的一种方式，同时能够经过水平扩展以达到增长消息吞吐量能力的目的。 下面先来看下RabbitMQ集群的总体方案：

葵花宝典之消息中间件—RabbitMQ（搭建篇) RabbitMQ集群的方案1.jpg

上面图中采用三个节点组成了一个RabbitMQ的集群，Exchange A（交换器，对于RabbitMQ基础概念不太明白的童鞋能够看下基础概念）的元数据信息在全部节点上是一致的，而Queue（存放消息的队列）的完整数据则只会存在于它所建立的那个节点上。，其余节点只知道这个queue的metadata信息和一个指向queue的owner node的指针。（1）RabbitMQ集群元数据的同步

RabbitMQ集群会始终同步四种类型的内部元数据（相似索引）：

a.队列元数据：队列名称和它的属性；

b.交换器元数据：交换器名称、类型和属性；

c.绑定元数据：一张简单的表格展现了如何将消息路由到队列；

d.vhost元数据：为vhost内的队列、交换器和绑定提供命名空间和安全属性；

所以，当用户访问其中任何一个RabbitMQ节点时，经过rabbitmqctl查询到的queue／user／exchange/vhost等信息都是相同的。

（2）为什么RabbitMQ集群仅采用元数据同步的方式

我想确定有很多同窗会问，想要实现HA方案，那将RabbitMQ集群中的全部Queue的完整数据在全部节点上都保存一份不就能够了么？（能够相似MySQL的主主模式嘛）这样子，任何一个节点出现故障或者宕机不可用时，那么使用者的客户端只要能链接至其余节点可以照常完成消息的发布和订阅嘛。

我想RabbitMQ的做者这么设计主要仍是基于集群自己的性能和存储空间上来考虑。第一，存储空间，若是每一个集群节点都拥有全部Queue的彻底数据拷贝，那么每一个节点的存储空间会很是大，集群的消息积压能力会很是弱（没法经过集群节点的扩容提升消息积压能力）；第二，性能，消息的发布者须要将消息复制到每个集群节点，对于持久化消息，网络和磁盘同步复制的开销都会明显增长。

（3）RabbitMQ集群发送/订阅消息的基本原理

RabbitMQ集群的工做原理图以下：

葵花宝典之消息中间件—RabbitMQ（搭建篇) RabbitMQ集群工做原理.jpg

场景一、客户端直接链接队列所在节点

若是有一个消息生产者或者消息消费者经过amqp-client的客户端链接至节点1进行消息的发布或者订阅，那么此时的集群中的消息收发只与节点1相关，这个没有任何问题；若是客户端相连的是节点2或者节点3（队列1数据不在该节点上），那么状况又会是怎么样呢？

场景二、客户端链接的是非队列数据所在节点

若是消息生产者所链接的是节点2或者节点3，此时队列1的完整数据不在该两个节点上，那么在发送消息过程当中这两个节点主要起了一个路由转发做用，根据这两个节点上的元数据（也就是上文提到的：指向queue的owner node的指针）转发至节点1上，最终发送的消息仍是会存储至节点1的队列1上。

一样，若是消息消费者所链接的节点2或者节点3，那这两个节点也会做为路由节点起到转发做用，将会从节点1的队列1中拉取消息进行消费。

2、RabbitMQ集群的搭建 （1）搭建RabbitMQ集群所须要安装的组件

在搭建RabbitMQ集群以前有必要在每台虚拟机上安装以下的组件包，分别以下：

a.Jdk 1.8

b.Erlang运行时环境，这里用的是otp_src_19.3.tar.gz (200MB+)

c.RabbitMq的Server组件，这里用的rabbitmq-server-generic-unix-3.6.10.tar.gz

关于如何安装上述三个组件的具体步骤，已经有很多博文对此进行了很是详细的描述，那么本文就再也不赘述了。有须要的同窗能够具体参考这些步骤来完成安装。

（2）搭建10节点组成的RabbitMQ集群

该节中主要展现的是集群搭建，须要确保每台机器上正确安装了上述三种组件，而且每台虚拟机上的RabbitMQ的实例可以正常启动起来。

a.编辑每台RabbitMQ的cookie文件，以确保各个节点的cookie文件使用的是同一个值,能够scp其中一台机器上的cookie至其余各个节点，cookie的默认路径为/var/lib/rabbitmq/.erlang.cookie或者$HOME/.erlang.cookie，节点之间经过cookie肯定相互是否可通讯。

b.配置各节点的hosts文件( vim /etc/hosts)

xxx.xxx.xxx.xxx rmq-broker-test-1 xxx.xxx.xxx.xxx rmq-broker-test-2 xxx.xxx.xxx.xxx rmq-broker-test-3 ...... xxx.xxx.xxx.xxx rmq-broker-test-10 c.逐个节点启动RabbitMQ服务

rabbitmq-server -detached d.查看各个节点和集群的工做运行状态

rabbitmqctl status, rabbitmqctl cluster_status e.以rmq-broker-test-1为主节点，在rmq-broker-test-2上：

rabbitmqctl stop_app rabbitmqctl reset rabbitmqctl join_cluster rabbit@rmq-broker-test-2 rabbitmqctl start_app 在其他的节点上的操做步骤与rmq-broker-test-2虚拟机上的同样。

d.在RabbitMQ集群中的节点只有两种类型：内存节点/磁盘节点，单节点系统只运行磁盘类型的节点。而在集群中，能够选择配置部分节点为内存节点。

内存节点将全部的队列，交换器，绑定关系，用户，权限，和vhost的元数据信息保存在内存中。而磁盘节点将这些信息保存在磁盘中，可是内存节点的性能更高，为了保证集群的高可用性，必须保证集群中有两个以上的磁盘节点，来保证当有一个磁盘节点崩溃了，集群还能对外提供访问服务。在上面的操做中，能够经过以下的方式，设置新加入的节点为内存节点仍是磁盘节点：

#加入时候设置节点为内存节点（默认加入的为磁盘节点） [root@mq-testvm1 ~]# rabbitmqctl join_cluster rabbit@rmq-broker-test-1 --ram #也经过下面方式修改的节点的类型 [root@mq-testvm1 ~]# rabbitmqctl changeclusternode_type disc | ram e.最后能够经过“rabbitmqctl cluster_status”的方式来查看集群的状态，上面搭建的10个节点的RabbitMQ集群状态（3个节点为磁盘即诶但，7个节点为内存节点）以下：

Cluster status of node 'rabbit@rmq-broker-test-1' [{nodes,[{disc,['rabbit@rmq-broker-test-1','rabbit@rmq-broker-test-2', 'rabbit@rmq-broker-test-3']}, {ram,['rabbit@rmq-broker-test-9','rabbit@rmq-broker-test-8', 'rabbit@rmq-broker-test-7','rabbit@rmq-broker-test-6', 'rabbit@rmq-broker-test-5','rabbit@rmq-broker-test-4', 'rabbit@rmq-broker-test-10']}]}, {running_nodes,['rabbit@rmq-broker-test-10','rabbit@rmq-broker-test-5', 'rabbit@rmq-broker-test-9','rabbit@rmq-broker-test-2', 'rabbit@rmq-broker-test-8','rabbit@rmq-broker-test-7', 'rabbit@rmq-broker-test-6','rabbit@rmq-broker-test-3', 'rabbit@rmq-broker-test-4','rabbit@rmq-broker-test-1']}, {cluster_name,<<"rabbit@mq-testvm1">>}, {partitions,[]}, {alarms,[{'rabbit@rmq-broker-test-10',[]}, {'rabbit@rmq-broker-test-5',[]}, {'rabbit@rmq-broker-test-9',[]}, {'rabbit@rmq-broker-test-2',[]}, {'rabbit@rmq-broker-test-8',[]}, {'rabbit@rmq-broker-test-7',[]}, {'rabbit@rmq-broker-test-6',[]}, {'rabbit@rmq-broker-test-3',[]}, {'rabbit@rmq-broker-test-4',[]}, {'rabbit@rmq-broker-test-1',[]}]}] （3）配置HAProxy

HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机，它是免费、快速而且可靠的一种解决方案。根据官方数据，其最高极限支持10G的并发。HAProxy支持从4层至7层的网络交换，即覆盖全部的TCP协议。就是说，Haproxy 甚至还支持 Mysql 的均衡负载。为了实现RabbitMQ集群的软负载均衡，这里能够选择HAProxy。

关于HAProxy如何安装的文章以前也有不少同窗写过，这里就再也不赘述了，有须要的同窗能够参考下网上的作法。这里主要说下安装完HAProxy组件后的具体配置。

HAProxy使用单一配置文件来定义全部属性，包括从前端IP到后端服务器。下面展现了用于7个RabbitMQ节点组成集群的负载均衡配置（另外3个磁盘节点用于保存集群的配置和元数据，不作负载）。同时，HAProxy运行在另一台机器上。HAProxy的具体配置以下：

#全局配置 global #日志输出配置，全部日志都记录在本机，经过local0输出 log 127.0.0.1 local0 info #最大链接数 maxconn 4096 #改变当前的工做目录 chroot /apps/svr/haproxy #以指定的UID运行haproxy进程 uid 99 #以指定的GID运行haproxy进程 gid 99 #以守护进程方式运行haproxy #debug #quiet daemon #debug #当前进程pid文件 pidfile /apps/svr/haproxy/haproxy.pid #默认配置 defaults #应用全局的日志配置 log global #默认的模式mode{tcp|http|health} #tcp是4层，http是7层，health只返回OK mode tcp #日志类别tcplog option tcplog #不记录健康检查日志信息 option dontlognull #3次失败则认为服务不可用 retries 3 #每一个进程可用的最大链接数 maxconn 2000 #链接超时 timeout connect 5s #客户端超时 timeout client 120s #服务端超时 timeout server 120s maxconn 2000 #链接超时 timeout connect 5s #客户端超时 timeout client 120s #服务端超时 timeout server 120s #绑定配置 listen rabbitmq_cluster bind 0.0.0.0:5672 #配置TCP模式 mode tcp #加权轮询 balance roundrobin #RabbitMQ集群节点配置,其中ip1~ip7为RabbitMQ集群节点ip地址 server rmq_node1 ip1:5672 check inter 5000 rise 2 fall 3 weight 1 server rmq_node2 ip2:5672 check inter 5000 rise 2 fall 3 weight 1 server rmq_node3 ip3:5672 check inter 5000 rise 2 fall 3 weight 1 server rmq_node4 ip4:5672 check inter 5000 rise 2 fall 3 weight 1 server rmq_node5 ip5:5672 check inter 5000 rise 2 fall 3 weight 1 server rmq_node6 ip6:5672 check inter 5000 rise 2 fall 3 weight 1 server rmq_node7 ip7:5672 check inter 5000 rise 2 fall 3 weight 1 #haproxy监控页面地址 listen monitor bind 0.0.0.0:8100 mode http option httplog stats enable stats uri /stats stats refresh 5s 在上面的配置中“listen rabbitmq_cluster bind 0.0.0.0：5671”这里定义了客户端链接IP地址和端口号。这里配置的负载均衡算法是roundrobin—加权轮询。与配置RabbitMQ集群负载均衡最为相关的是“ server rmq_node1 ip1:5672 check inter 5000 rise 2 fall 3 weight 1”这种，它标识而且定义了后端RabbitMQ的服务。主要含义以下:

(a)“server ”部分：定义HAProxy内RabbitMQ服务的标识；

(b)“ip1:5672”部分：标识了后端RabbitMQ的服务地址；

(c)“check inter ”部分：表示每隔多少毫秒检查RabbitMQ服务是否可用；

(d)“rise ”部分：表示RabbitMQ服务在发生故障以后，须要多少次健康检查才能被再次确承认用；

(e)“fall ”部分：表示须要经历多少次失败的健康检查以后，HAProxy才会中止使用此RabbitMQ服务。

#启用HAProxy服务 [root@mq-testvm12 conf]# haproxy -f haproxy.cfg 启动后，便可看到以下的HAproxy的界面图：

葵花宝典之消息中间件—RabbitMQ（搭建篇) RabbitMQ集群Haproxy部署的UI界面.jpg

（4）RabbitMQ的集群架构设计图

通过上面的RabbitMQ10个节点集群搭建和HAProxy软弹性负载均衡配置后便可组建一个中小规模的RabbitMQ集群了，然而为了可以在实际的生产环境使用还须要根据实际的业务需求对集群中的各个实例进行一些性能参数指标的监控，从性能、吞吐量和消息堆积能力等角度考虑，能够选择Kafka来做为RabbitMQ集群的监控队列使用。所以，这里先给出了一个中小规模RabbitMQ集群架构设计图：

葵花宝典之消息中间件—RabbitMQ（搭建篇) RabbitMQ小规模集群的架构设计图(附加了监控部分).png

对于消息的生产和消费者能够经过HAProxy的软负载将请求分发至RabbitMQ集群中的Node1～Node7节点，其中Node8～Node10的三个节点做为磁盘节点保存集群元数据和配置信息。鉴于篇幅缘由这里就不在对监控部分进行详细的描述的，会在后续篇幅中对如何使用RabbitMQ的HTTP API接口进行监控数据统计进行详细阐述。

3、总结 本文主要详细介绍了RabbitMQ集群的工做原理和如何搭建一个具有负载均衡能力的中小规模RabbitMQ集群的方法，并最后给出了RabbitMQ集群的架构设计图。限于笔者的才疏学浅，对本文内容可能还有理解不到位的地方，若有阐述不合理之处还望留言一块儿探讨。

写在后面:

码字不易看到最后了，那就点个关注呗，只收藏不点关注的都是在耍流氓！

关注并私信我“架构”，免费送一些Java架构资料，先到先得！