MQ RabbitMQ 高可用集群（二）：集群搭建

1 集群节点安装

单节点安装RabbitMQ，可参考博文：

MQ RocketMQ安装部署和配置： https://blog.csdn.net/qq_15769939/article/details/115800384

以上操作三个节点（71、72、73）同时进行操作

2 文件同步配置

选择71、72、73任意一个节点为Master（这里选择71为Master），也就是说我们需要把71的Cookie文件同步到72、73节点上去，进入/var/lib/rabbitmq目录下，把/var/lib/rabbitmq/.erlang.cookie文件的权限修改为777，原来是400；然后把.erlang.cookie文件copy到各个节点下；最后把所有cookie文件权限还原为400即可。

//进入目录修改权限；远程copy72、73节点
scp /var/lib/rabbitmq/.erlang.cookie 192.168.11.72:/var/lib/rabbitmq/
scp /var/lib/rabbitmq/.erlang.cookie 192.168.11.73:/var/lib/rabbitmq/

3 集群配置

3.1 停止服务

首先停止3个节点的服务：(这里不能使用原来的命令：/etc/init.d/rabbitmq-server stop)

rabbitmqctl stop

3.2 配置集群

3.2.1 组成集群

接下来我们就可以使用集群命令，配置71、72、73为集群模式，3个节点（71、72、73）执行启动命令，后续启动集群使用此命令即可。

rabbitmq-server -detached

3.2.2 slave加入集群

加入集群操作（重新加入集群也是如此，以最开始的主节点为加入节点）

//注意做这个步骤的时候：需要配置/etc/hosts 必须相互能够寻址到
bhz72：rabbitmqctl stop_app
bhz72：rabbitmqctl join_cluster --ram rabbit@bhz71
bhz72：rabbitmqctl start_app
bhz73：rabbitmqctl stop_app
bhz73：rabbitmqctl join_cluster rabbit@bhz71
bhz73：rabbitmqctl start_app
//在另外其他节点上操作要移除的集群节点
rabbitmqctl forget_cluster_node rabbit@bhz71

3.2.3 修改集群名称

修改集群名称（默认为第一个node名称）

rabbitmqctl set_cluster_name rabbitmq_cluster1

3.3 查看集群状态

3.3.1 命令查看

在集群的任意一个节点执行命令：查看集群状态

rabbitmqctl cluster_status

3.3.2 管理界面查看

访问任意一个管控台节点：http://192.168.11.71:15672 如图所示

4 配置镜像队列

设置镜像队列策略（在任意一个节点上执行）

rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"}'

将所有队列设置为镜像队列，即队列会被复制到各个节点，各个节点状态一致，RabbitMQ高可用集群就已经搭建好了,我们可以重启服务，查看其队列是否在从节点同步。

5 消息一致性问题

5.1 介绍

在使用rabbitmq中，消息的一致性是非常重要的一个话题。下面我们来研究一下，在数据一致性方面，有哪些需要关注的。发送者发送消息出来，在数据一致性的要求下，我们通常认为必须达到以下条件：

• broker持久化消息
• publisher知道消息已经成功持久化

首先，我们可以采用事务来解决此问题。每个消息都必须经历以上两个步骤，就算一次事务成功。

事务是同步的。因此，如果采用事务，发送性能必然很差。官方给出来的性能是：

It takes a bit more than 4 minutes to publish 10000 messages.

异步的方法的效率是事务方法效率的100倍。

5.2 解决方案

我们可以采用异步的方式来解决此问题。publisher发送消息后，不进行等待，而是异步监听是否成功。这种方式又分为两种模式，一种是return，另一种是confirm. 前一种是publisher发送到exchange后，异步收到消息。第二种是publisher发送消息到exchange,queue,consumer收到消息后才会收到异步收到消息。可见，第二种方式更加安全可靠。如下所示：

但是，异步也存在些局限性。如果一旦出现broker挂机或者网络不稳定，broker已经成功接收消息，但是publisher并没有收到confirm或return.这时，对于publisher来说，只能重发消息解决问题。而在这里面，我们会发生重复消息的问题。当然，如果业务类型要求数据一致性非常高，可以采用低效率的事务型解决方案：引用：http://www.rabbitmq.com/blog/2011/02/10/introducing-publisher-confirms/

6 相关信息

上一篇：MQ RabbitMQ 高可用集群（一）：架构设计

下一篇：MQ RabbitMQ 高可用集群（三）：Ha-Proxy安装和配置

博文不易，辛苦各位猿友点个关注和赞，感谢