当单台 RabbitMQ 服务器的处理消息的能力达到瓶颈时，此时可以通过 RabbitMQ 集群来进行扩展，从而达到提升吞吐量的目的。RabbitMQ 集群是一个或多个节点的逻辑分组，集群中的每个节点都是对等的，每个节点共享所有的用户，虚拟主机，队列，交换器，绑定关系，运行时参数和其他分布式状态等信息。一个高可用，负载均衡的 RabbitMQ 集群架构应类似下图：

这里对上面的集群架构做一下解释说明：

​ 首先一个基本的 RabbitMQ 集群不是高可用的，虽然集群共享队列，但在默认情况下，消息只会被路由到某一个节点的符合条件的队列上，并不会同步到其他节点的相同队列上。假设消息路由到 node1 的 my-queue 队列上，但是 node1 突然宕机了，那么消息就会丢失，想要解决这个问题，需要开启队列镜像，将集群中的队列彼此之间进行镜像，此时消息就会被拷贝到处于同一个镜像分组中的所有队列上。

​ 其次 RabbitMQ 集群本身并没有提供负载均衡的功能，也就是说对于一个三节点的集群，每个节点的负载可能都是不相同的，想要解决这个问题可以通过硬件负载均衡或者软件负载均衡的方式，这里我们选择使用 HAProxy 来进行负载均衡，当然也可以使用其他负载均衡中间件，如LVS等。HAProxy 同时支持四层和七层负载均衡，并基于单一进程的事件驱动模型，因此它可以支持非常高的井发连接数。

接着假设我们只采用一台 HAProxy ，那么它就存在明显的单点故障的问题，所以至少需要两台 HAProxy ，同时这两台 HAProxy 之间需要能够自动进行故障转移，通常的解决方案就是 KeepAlived 。KeepAlived 采用 VRRP (Virtual Router Redundancy Protocol，虚拟路由冗余协议) 来解决单点失效的问题，它通常由一组一备两个节点组成，同一时间内只有主节点会提供对外服务，并同时提供一个虚拟的 IP 地址 (Virtual Internet Protocol Address ，简称 VIP) 。 如果主节点故障，那么备份节点会自动接管 VIP 并成为新的主节点 ，直到原有的主节点恢复。

下面我们开始进行搭建，这里我使用三台主机，主机名分别为 node11， node12 和 node13，其功能分配如下：

```Python 两者兼容关系：https://www.rabbitmq.com/which-erlang.html 官方安装文档：https://www.rabbitmq.com/install-rpm.html#downloads 系统版本：CentOS 7.X 提供两种安装方式，但是注意两者依赖要统一

https://github.com/rabbitmq/erlang-rpm/releases?page=3 ```

Erlang官网：https://www.erlang-solutions.com/downloads/# 下载Erlang地址：http://www.rpmfind.net/linux/rpm2html/search.php?query=erlang 下载Erlang地址：Releases · rabbitmq/erlang-rpm · GitHub

默认情况下，访问RabbitMQ服务的用户名和密码都是"guest",这个账户有限制，默认只能通过本地网络(如localhost)访问，远程网络访问受限，使用默认的用户 guest / guest （此也为管理员用户）登陆，会发现无法登陆，报错：User can only log in via localhost。那是因为默认是限制了guest用户只能在本机登陆，也就是只能登陆localhost:15672。所以在实现生产和消费消息之前，需要另外添加一个用户，并设置相应的访问权限

分别修改各个虚拟机主机名

修改每台机器的 /etc/hosts 文件

这里我们为所有队列开启镜像配置，其语法如下：

在上面我们指定了 ha-mode 的值为 all ，代表消息会被同步到所有节点的相同队列中。这里我们之所以这样配置，因为我们本身只有三个节点，因此复制操作的性能开销比较小。如果你的集群有很多节点，那么此时复制的性能开销就比较大，此时需要选择合适的复制系数。通常可以遵循过半写原则，即对于一个节点数为 n 的集群，只需要同步到 n/2+1 个节点上即可。此时需要同时修改镜像策略为 exactly，并指定复制系数 ha-params，示例命令如下：

除此之外，RabbitMQ 还支持使用正则表达式来过滤需要进行镜像操作的队列，示例如下：

此时只会对 ha 开头的队列进行镜像。更多镜像队列的配置说明，可以参考官方文档：Highly Available (Mirrored) Queues

配置完成后，可以通过 Web UI 界面查看任意队列的镜像状态，情况如下：

没有一个直接的命令可以关闭整个集群，需要逐一进行关闭。但是需要保证在重启时，最后关闭的节点最先被启动。如果第一个启动的不是最后关闭的节点，那么这个节点会等待最后关闭的那个节点启动，默认进行 10 次连接尝试，超时时间为 30 秒，如果依然没有等到，则该节点启动失败。

这带来的一个问题是，假设在一个三节点的集群当中，关闭的顺序为 node11，node12，node13，如果 node11 因为故障暂时没法恢复，此时 node12 和 node13 就无法启动。想要解决这个问题，可以先将 node11 节点进行剔除，命令如下：

重置当前节点

重新加入集群

完成后重新检查 RabbitMQ 集群状态

除了在当前节点重置集群外，还可在集群其他正常节点将节点踢出集群

我们可以将节点的类型从RAM更改为Disk，反之亦然。假设我们想要反转rabbit@node12和rabbit@node13的类型，将前者从RAM节点转换为磁盘节点，而后者从磁盘节点转换为RAM节点。为此，我们可以使用change_cluster_node_type命令。必须首先停止节点。

yum 源安装目前版本比较低，采用源码安装方式。

HAProxy 官方下载地址为：www.haproxy.org/#down ，如果这个网站无法访问，也可以从 src.fedoraproject.org/repo/pkgs/h… 上进行下载。这里我下载的是 2.x 的版本，下载后进行解压：

进入解压后根目录，执行下面的编译命令：

配置环境变量：

使得配置的环境变量立即生效：

检查安装是否成功：

新建配置文件 haproxy.cfg，这里我新建的位置为：/etc/haproxy/haproxy.cfg。

文件内容如下：

负载均衡的主要配置在 listen rabbitmq_cluster 下，这里指定负载均衡的方式为加权轮询，同时定义好健康检查机制：

以上配置代表对地址为 node11:5672 的 node1 节点每隔 5 秒进行一次健康检查，如果连续两次的检查结果都是正常，则认为该节点可用，此时可以将客户端的请求轮询到该节点上；如果连续 3 次的检查结果都不正常，则认为该节点不可用。weight 用于指定节点在轮询过程中的权重。

以上搭建步骤在 node11 和 node12 上完全相同，搭建完成使用以下命令启动服务：

开启监控页面访问端口

启动后可以在监控页面进行查看，端口为设置的 8100，完整地址为：http://192.168.114.11:8100/stats ，页面情况如下：

所有节点都为绿色，代表节点健康。此时证明 HAProxy 搭建成功，并已经对 RabbitMQ 集群进行监控。

接着就可以搭建 Keepalived 来解决 HAProxy 故障转移的问题。这里我在 node11 和 node12 和 node13上安装 KeepAlived ，两台主机上的搭建的步骤完全相同，只是部分配置略有不同，具体如下：

Keepalived 可以使用 yum 直接安装，在 MASTER 服务器和 BACKUP 服务器执行：

本例使用 ens33 这块网卡。

完整配置如下：

备份节点的配置与主节点基本相同，但是需要修改其 state 为 BACKUP；同时其优先级 priority 需要比主节点低。

完整配置如下：

以上配置定义了 Keepalived 的 MASTER 节点和 BACKUP 节点，并设置对外提供服务的虚拟 IP 为 192.168.114.200。此外最主要的是定义了通过 haproxy_check.sh 来对 HAProxy 进行监控，这个脚本需要我们自行创建，内容如下：

创建后为其赋予执行权限

这个脚本主要用于判断 HAProxy 服务是否正常，如果不正常且无法启动，此时就需要将本机 Keepalived 关闭，从而让虚拟 IP 漂移到备份节点。

配置 IP 转发，需要修改配置文件 /etc/sysctl.conf，默认只有 root 可以修改，分别在 MASTER 和 BACKUP上修改。

node11 和node12和node13 上启动 KeepAlived 服务，命令如下：

启动后此时 node11 为主节点，可以在 node11 上使用 ip a 命令查看到虚拟 IP 的情况：

此时只有 node11 上是存在虚拟 IP 的，而 node12上是没有的。

漂移规则如下：

默认使用 MASTER 服务器（192.168.114.11），虚拟 IP 为 192.168.114.200，此时 MASTER 服务器会有 2 个IP。 当 MASTER 出问题时，IP 会漂移到 BACKUP 服务器（192.168.114.12），此时 BACKUP 服务器会有 2 个IP。 当 MASTER 重新启动后，虚拟 IP 又会漂移回 MASTER 服务器。

这里我们验证一下故障转移，因为按照我们上面的检测脚本，如果 HAProxy 已经停止且无法重启时 KeepAlived 服务就会停止，这里我们直接使用以下工具进行验证。

安装 tcpdump 包

在 MASTER 服务器上执行

这表明 MASTER 在向 BACKUP 广播，MASTER 在线。此时虚拟 IP 时挂在 MASTER 上的，如果想退出, 按 Ctrl+C。

如果 MASTER 停止 keepalived，虚拟 IP 会漂移到 BACKUP 服务器上。 我们可以测试一下：

首先，停止 MASTER 的 keepalived

然后，在 MASTER 服务器上查看 VRRP 服务

这表明 MASTER 收到 BACKUP 的广播，此时虚拟 IP 时挂在 BACKUP 服务器上。

此时再次使用 ip a 分别查看，可以发现 MASTER 上的 VIP 已经漂移到 BACKUP 上，情况如下：

再次重启 MASTER 服务器，会发现 VIP 又重新漂移回 MASTER 服务器。

此时对外服务的 VIP 依然可用，代表已经成功地进行了故障转移。至此集群已经搭建成功，任何需要发送或者接受消息的客户端服务只需要连接到该 VIP 即可

keepalived 默认将日志输出到系统日志/var/log/messages中，因为系统日志很多，查询问题时相对麻烦。

我们可以将 keepalived 的日志单独拿出来，这需要修改日志输出路径。

修改 Keepalived 配置

更改如下 :

把 KEEPALIVED_OPTIONS=”-D” 修改为 KEEPALIVED_OPTIONS=”-D -d -S 0”，其中 -S 指定 syslog 的 facility

修改 /etc/rsyslog.conf 末尾添加

重启日志记录服务

重启 keepalived

此时，可以从 /var/log/keepalived.log 查看日志了。

机房突然停电，rabbitmq的主机异常断电，集群服务全部需要重启。但是在执行service rabbitmq-server start 启动主节点服务的时候，没有反应，服务没有启动，命令也执行卡住了。必须Ctrl+C结束进程：

注意，这只是主节点的处理方法，在两台从节点，需要做如下操作： 1、检查两台从节点的/var/lib/rabbitmq/.erlang.cookie文件内容是否和主节点是保持一致的 2、删除原有的数据/var/lib/rabbitmq/mnesia目录，执行rabbitmq-server -detached重新启动服务 3、在两台从节点上执行下面的命令，重新加入集群：

github地址：GitHub - hpf0532/flask-celery-demo

https://juejin.im/post/6844904071183220749 RabbitMQ 官方文档 —— 集群指南：http://www.rabbitmq.com/clustering.… RabbitMQ 官方文档 —— 高可用镜像队列：http://www.rabbitmq.com/ha.html HAProxy 官方配置手册：http://cbonte.github.io/haproxy-dco… KeepAlived 官方配置手册：http://www.keepalived.org/manpage.htm…

版权声明：本文为CSDN博主「请叫我longge」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

参考链接：

​ 搭建rabbitmq集群：https://blog.csdn.net/qq_28533563/article/details/107932737

​ 解决mq宕机存在的问题：https://blog.51cto.com/u_10950710/2116406

​ mq集群搭建：RabbitMQ 集群 - 简书 (jianshu.com)