一、目的

​ 在使用 RabbitMq集群时可能会遇到集群中某个节点出现异常或者连接数过多的情况，这个时候与该节点连接的Consumer将会断开，Publisher也会无法将消息发送至集群。为了解决这些问题，本文中将使用 HAProxy来代理集群，实现多个节点的负载均衡以及在某个节点异常时自动将连接切换至其他正常节点等功能。

二、HAProxy安装配置（Centos 7）

1. 安装 HAProxy
   1. 下载最新稳定版2.0.8并解压

      // PWD：/opt/ci123/www/html/rabbitMq/
      wget https://www.haproxy.org/download/2.0/src/haproxy-2.0.8.tar.gz
      tar xf haproxy-2.0.8.tar.gz
      

   2. 查看系统内核版本来指定编译版本

      uname -r
      3.10.0-862.6.3.el7.x86_64
      

      版本参考：

      ```

   </ol>

   <ul>
   <li>linux22 for Linux 2.2</li>
   <li>linux24 for Linux 2.4 and above (default)</li>
   <li>linux24e for Linux 2.4 with support for a working epoll (> 0.21)</li>
   <li>linux26 for Linux 2.6 and above</li>
   <li>linux2628 for Linux 2.6.28, 3.x, and above (enables splice and tproxy)</li>
   <li>solaris for Solaris 8 or 10 (others untested)</li>
   <li>freebsd for FreeBSD 5 to 10 (others untested)</li>
   <li>netbsd for NetBSD</li>
   <li>osx for Mac OS/X</li>
   <li>openbsd for OpenBSD 5.7 and above</li>
   <li>aix51 for AIX 5.1</li>
   <li>aix52 for AIX 5.2</li>
   <li>cygwin for Cygwin</li>
   <li>haiku for Haiku</li>
   <li>generic for any other OS or version.</li>
   <li><p>custom to manually adjust every setting
   ```

   根据版本参考，这里我们选择linux2628版本进行编译。

   1. 编译到指定目录

      cd haproxy-2.0.8
      make TARGET=linux2628 PREFIX=/opt/ci123/haproxy
      
      // 这里出现报错，从2.0版本开始linux2628已被废弃
      Target 'linux2628' was removed from HAProxy 2.0 due to being irrelevant and
      often wrong. Please use 'linux-glibc' instead or define your custom target
      by checking available options using 'make help TARGET=<your-target>'.
      
      // 根据提示修改参数后编译
      make TARGET=linux-glibc PREFIX=/opt/ci123/haproxy
      make install PREFIX=/opt/ci123/haproxy
      

   3. 配置
      1. 复制 haproxy命令至全局变量

         cp /opt/ci123/haproxy/sbin/haproxy /usr/bin/
         

      2. 创建系统用户

         useradd -r haproxy
         

      3. 添加haproxy配置文件
         1. haproxy配置文件由五部分组成：
         • global： 参数是进程级的，通常和操作系统相关。这些参数一般只设置一次，如果配置无误，就不需要再次配置进行修改。
      • default：默认参数。
        • frontend：用于接收客户端请求的前端节点，可以设置相应的转发规则来指定使用哪个backend。
        • backend：后端服务器代理配置，可实现代理多台服务器实现负载均衡、为请求添加额外报文数据等功能。
        • listen：是frontend和backend的结合，通常只对tcp流量有用。
      1. 添加配置文件/opt/ci123/haproxy/conf/haproxy.cfg

         ```
         # 全局配置
         global
         log 127.0.0.1 local3 # 设置日志
         pidfile /opt/ci123/haproxy/logs/haproxy.pid
         maxconn 4000 # 最大连接数
         user haproxy
         group haproxy
         daemon # 守护进程运行

         # 默认配置
         defaults
         log global
         mode tcp # 默认的模式mode { tcp|http|health }，tcp是4层，http是7层，health只会返回OK
         option httplog # http 日志格式，仅在http模式下可用
         option dontlognull # 不记录健康检查日志信息；
         option redispatch # serverId对应的服务器挂掉后,强制定向到其他健康的服务器
         option http-server-close
         #option abortonclose # 当服务器负载很高的时候，自动结束掉当前队列处理比较久的链接；
         #option forwardfor # 如果后端服务器需要获得客户端真实ip需要配置的参数，可以从Http Header中获得客户端ip；
         #option httpclose # 主动关闭http通道,每次请求完毕后主动关闭http通道,ha-proxy不支持keep-alive,只能模拟这种模式的实现;<br />
         balance roundrobin # 负载均衡算法,轮询；
         retries 3 # 重试次数；

         <pre class="prism-highlight line-numbers" data-start="1"><code class="language-null"> timeout http-request 10s # 客户端建立连接但不请求数据时，关闭客户端连接；
         timeout queue 1m # 高负载响应haproxy时，会把haproxy发送来的请求放进一个队列中，timeout queue定义放入这个队列的超时时间；
         timeout connect 10s # 定义haproxy将客户端请求转发至后端服务器所等待的超时时间；
         timeout client 1m # 客户端非活动状态的超长时间(默认毫秒)
         timeout server 1m # 服务端与客户端非活动状态连接的超时时间。(默认毫秒)
         timeout http-keep-alive 10s # 定义保持连接的超时时长；
         timeout check 10s # 心跳检测超时；
         maxconn 3000 # 每个server最大的连接数；
         </code></pre>

         #前端配置
         frontend rabbitmq_cluster_front
         bind 0.0.0.0:10000 # http请求的端口，会被转发到设置的ip及端口
         default_backend rabbitmq_cluster_back

         # 后端配置
         backend rabbitmq_cluster_back
         #roundrobin 轮询方式
         balance roundrobin # 负载均衡的方式,轮询方式

         <pre class="prism-highlight line-numbers" data-start="1"><code class="language-null"> # 配置Rabbitmq连接负载均衡
         # 需要转发的ip及端口
         # inter 2000 健康检查时间间隔2秒
         # rise 3 检测多少次才认为是正常的
         # fall 3 失败多少次才认为是不可用的
         # weight 30 权重
         server clusterRabbit1 192.168.3.14:5672 check inter 2000 rise 3 fall 3 weight 30
         server clusterRabbit2 192.168.3.14:5673 check inter 2000 rise 3 fall 3 weight 30
         </code></pre>

         # 统计页面配置
         listen admin_stats<br />
         bind 0.0.0.0:10080 # 监听IP和端口，为了安全可以设置本机的局域网IP及端口；
         mode http
         option httplog # 采用http日志格式<br />
         stats refresh 30s # 统计页面自动刷新时间<br />
         stats uri /haproxy # 状态管理页面，通过/haproxy来访问
         stats realm Haproxy Manager # 统计页面密码框上提示文本<br />
         stats auth duomai:shijiemori@2012 # 统计页面用户名和密码设置<br />
         #stats hide-version # 隐藏统计页面上HAProxy的版本信息
         ```

         1. 配置日志 rsyslog

         vim /etc/rsyslog.conf
         # 取消如下2行注释
         $ModLoad imudp
         $UDPServerRun 51
         
         # 新增配置（自定义的日志设备）
         local3.*  /opt/ci123/haproxy/logs/haproxy.log
         
         # 重启rsyslog服务
         systemctl restart rsyslog
         

         1. 启动 haproxy

         haproxy -f /opt/ci123/haproxy/conf/haproxy.cfg
         

         访问统计页面出现如下界面：

         

   三、集群测试

   ​ 沿用上一篇【RabbitMq 镜像队列集群搭建】中的集群测试环境，在测试中将Publiser和Consumer的连接替换为HAProxy的地址192.168.3.14:10000。

   1. 测试环境
      1. 节点：
         1. 节点一：
         • clusterRabbit1
         • 端口：192.168.3.14:5672
           1. 节点二：
         • clusterRabbit2
         • 端口：192.168.3.14:5673
      2. 队列：
         1. 节点一 rabbit@clusterRabbit1：
            1. 队列一：
            • name：clusterRabbit1Queue1
            • routing_key：clusterRabbit1key
            1. 队列二：
            • name：clusterRabbit1Queue2
            • routing_key：clusterRabbitCommonKey
         2. 节点二 rabbit@clusterRabbit2：
            1. 队列三：
            • name：clusterRabbit2Queue1
            • routing_key：clusterRabbit2key
            1. 队列四：
            • name：clusterRabbit2Queue2
            • routing_key：clusterRabbitCommonKey（与队列二 相同）
   2. 启动消费者
      1. 消费者
         1. 消费者一：
         • 连接节点：节点一 rabbit@clusterRabbit1
         • 消费队列：队列一 clusterRabbit1Queue1
           1. 消费者二：
         • 连接节点：节点一 rabbit@clusterRabbit1
         • 消费队列：队列二 clusterRabbit1Queue2
           1. 消费者三：
         • 连接节点：节点二 rabbit@clusterRabbit2
         • 消费队列：队列三 clusterRabbit2Queue1
           1. 消费者四：
         • 连接节点：节点二 rabbit@clusterRabbit2
         • 消费队列：队列四 clusterRabbit2Queue2
      2. 启动结果：

         启动成功，但是在一分钟后客户端异常退出，原因是HAProxy设置了timeout client 1m 和 timeout server 1m，消费者在一分钟内都没有接收到消息导致被判定为不活跃连接从而被删除。

         由于HAProxy默认不支持长连接，上述问题可以使用pm2管理消费者的方法来解决，消费者进程在不活跃退出后pm2将自动重启此进程。

   3. 发布消息

      1. 发布clusterRabbit1key消息
      • 消费者一 成功收到消息。
        1. 发布clusterRabbitCommonKey消息
      • 消费者二/四 成功收到消息。

   4. 关闭节点二rabbit@clusterRabbit2后再次发布消息

   • 连接节点二的消费者先退出后重新使用HAProxy成功连接。
   • 发布的消息均能被成功消费。

   四、使用说明

   1. HAProxy默认不支持tcp 长连接，需要使用PM2之类的守护进程管理工具或者长连接技术来实现rabbitMq客户端持续连接。
   2. HAProxy通过活跃检测机制来判定负载均衡中的节点是否可用， 当rabbitMq集群中某个节点不可用时，在经过一段时间的活跃检测之后，HAProxy将弃用该节点直至节点恢复。在这种情况下，rabbitMq消费者将断开连接后选择剩余可用的节点再次启动，客户端发布时也会自动选择剩余可用的节点。
   3. 在rabbitMq集群中某个节点宕机之后，HAProxy会自动使用可用的集群节点，所以不会出现在HAProxy活跃检测期间发布消息出现一半成功一半失败的情况，所有的消息都将通过可用的集群节点发布至集群。

建议食用本文前请先阅读【RabbitMq 普通集群搭建】篇

一、RabbitMq镜像

1. 镜像： rabbitmq:3.8-management
2. 启动参数：
   • --name: 容器名称
   • -h / --hostname：rabbitMq默认节点的 host
   • -v：文件挂载映射
   • -p：端口映射
     • 5672：容器内默认的rabbitMq 启动端口
     • 15672：容器内默认的rabbitMq 管理插件启动端口
3. 环境变量：（支持所有rabbitMq环境变量）
   • RABBITMQ_NODENAME：节点名称，缺省为 rabbit@[hostname]
   • RABBITMQ_DEFAULT_USER：默认用户名，缺省为guset
   • RABBITMQ_DEFAULT_PASS：默认密码，缺省为 guest
   • RABBITMQ_DEFAULT_VHOST：默认虚拟主机，缺省为/
   • RABBITMQ_ERLANG_COOKIE：erlang.cookie值

二、搭建集群

1. 启动多份rabbitMq容器

   # 启动节点一
   docker run -d --hostname clusterRabbit1 --name clusterRabbit1 -p 15672:15672 -p 5672:5672 -e RABBITMQ_ERLANG_COOKIE='rabbitcookie' -v /opt/ci123/www/html/rabbitMq/clusterRabbit1:/var/lib/rabbitmq rabbitmq:3.8-management
   
   # 启动节点二
   docker run -d --hostname clusterRabbit2 --name clusterRabbit2 -p 5673:5672 --link clusterRabbit1:clusterRabbit1 -e RABBITMQ_ERLANG_COOKIE='rabbitcookie' -v /opt/ci123/www/html/rabbitMq/clusterRabbit2:/var/lib/rabbitmq rabbitmq:3.8-management
   

• /var/lib/rabbitmq 是容器内部文件数据存放目录，使用-v进行文件目录挂载。
• 多个容器之间使用--link <name or id>:alias连接，否则需要自行在各个容器添加供rabbitMq 相互访问的host。
• Erlang Cookie值必须相同，rabbitMQ是通过Erlang实现的，Erlang Cookie相当于不同节点之间相互通讯的秘钥，Erlang节点通过交换Erlang Cookie获得认证。

1. 启动集群
   1. 设置节点二 rabbit@clusterRabbit2,加入节点一 rabbit@clusterRabbit1的集群

      rabbitmqctl stop_app
      rabbitmqctl reset
      rabbitmqctl join_cluster rabbit@clusterRabbit1
      rabbitmqctl start_app
      

   2. 查看rabbitMq管理后台集群数据

      

2. 一键化启动脚本

   #!bin/sh
   # 启动节点一
   docker run -d --hostname clusterRabbit1 --name clusterRabbit1 -p 15672:15672 -p 5672:5672 -e RABBITMQ_ERLANG_COOKIE='rabbitcookie' -v /opt/ci123/www/html/rabbitMq/clusterRabbit1:/var/lib/rabbitmq rabbitmq:3.8-management
   
   # 启动节点二
   docker run -d --hostname clusterRabbit2 --name clusterRabbit2 -p 5673:5672 --link clusterRabbit1:clusterRabbit1 -e RABBITMQ_ERLANG_COOKIE='rabbitcookie' -v /opt/ci123/www/html/rabbitMq/clusterRabbit2:/var/lib/rabbitmq rabbitmq:3.8-management
   
   echo "即将开始初始化"
   sleep 5
   # 加入集群
   docker exec -it clusterRabbit2 sh -c 'rabbitmqctl stop_app && rabbitmqctl reset && rabbitmqctl join_cluster rabbit@clusterRabbit1 && rabbitmqctl start_app'
   
   # 添加虚拟主机
   docker exec -it clusterRabbit1 sh -c 'rabbitmqctl add_vhost cluster'
   
   # 添加用户
   docker exec -it clusterRabbit1 sh -c 'rabbitmqctl add_user api_management shijiemori2012'
   
   # 添加用户权限
   docker exec -it clusterRabbit1 sh -c 'rabbitmqctl set_permissions -p cluster api_management ".*" ".*" ".*"'
   
   # 设置用户标签
   docker exec -it clusterRabbit1 sh -c 'rabbitmqctl set_user_tags api_management administrator'
   

一、集群概念

​ RabbitMQ集群是一个或多个节点的逻辑分组，每个节点共享用户、虚拟主机、队列、交换、绑定路由、运行时参数和其他分布式状态。集群中的节点可以动态地添加/删除，RabbitMQ代理一开始都运行在单个节点上，可以将这些节点连接到集群中，然后再将其转换回各个代理。

1. 默认情况下，RabbitMq将复制除消息队列外的所有数据至集群中的每一个节点。而消息队列的完整数据只会存放于创建该队列的节点上，其余节点仅保存该队列的元数据和指针（类似于索引）。如果需要复制队列，则需要启用镜像队列集群。

2. 集群中每个节点是平等的，不存在主从和特殊的节点。

3. 集群中的节点通过Erlang Cookie相互通信，每个节点必须具有相同的cookie。

4. 节点分为磁盘节点和RAM节点，RAM节点只在RAM中存储内部数据库表，并不存储包括消息、消息存储索引、队列索引和其他节点状态等数据，RAM节点的性能更加高效，但是由于数据是非持久化的，一旦宕机将无法恢复。默认创建的都是磁盘节点。

5. 单节点拓扑图如下，集群的拓扑是基于多个Node节点的扩展。

   

二、配置需求

1. 配置方式
   • config 文件配置
   • rabbitmqctl命令配置（下文中使用此方法配置）
2. 集群中的节点名必须是唯一的
   • 可以在启动时使用环境变量RABBITMQ_NODENAME设置
   • 节点名由[节点名称]@[host]组成
3. 各个节点的启动端口可以被成功连接
4. 节点之间通过节点名相互访问，要求各个节点之间的host可以相互进行DNS解析
5. 每个节点之间必须配置相同的Erlang Cookie(多机环境需要额外配置)

三、集群配置

1. 启动多个独立的节点

   RABBITMQ_NODE_PORT=5674 RABBITMQ_NODE_IPDDRESS=192.168.0.235  RABBITMQ_SERVER_START_ARGS="-rabbitmq_management listener [{port,15673}]" RABBITMQ_NODENAME="clusterRabbit1@VM235"  /usr/local/rabbitmq/3.1.3/sbin/rabbitmq-server -detached
   RABBITMQ_NODE_PORT=5675 RABBITMQ_NODE_IPDDRESS=192.168.0.235  RABBITMQ_SERVER_START_ARGS="-rabbitmq_management listener [{port,15674}]" RABBITMQ_NODENAME="clusterRabbit2@VM235" /usr/local/rabbitmq/3.1.3/sbin/rabbitmq-server -detached
   

   执行完成后，分别创建了名称为clusterRabbit1@VM235,clusterRabbit2@VM235的两个节点。

   VM235需要提前配置host文件，确保各个节点之间的host可以相互进行DNS解析。

2. 创建集群

   1. 关闭节点clusterRabbit1@VM235

      ./rabbitmqctl -n clusterRabbit1@VM235 stop_app
      

   2. 重置节点clusterRabbit1@VM235

      ./rabbitmqctl -n clusterRabbit1@VM235 reset
      

      必须重置节点才能加入现有集群，重置节点将删除该节点上以前存在的所有资源和数据。这意味着节点不能在成为集群的成员时保留其现有数据，节点中的数据需要进行额外的备份和恢复。

   3. 将节点clusterRabbit1@VM235加入clusterRabbit2@VM235的集群

      ./rabbitmqctl -n clusterRabbit1@VM235 join_cluster clusterRabbit2@VM235
      

   4. 启动节点clusterRabbit1@VM235

      ./rabbitmqctl -n clusterRabbit1@VM235 start_app
      

   5. 查看集群信息

      ./rabbitmqctl -n clusterRabbit1@VM235 cluster_status
      结果：
      Cluster status of node clusterRabbit1@VM235 ...
      [{nodes,[{disc,[clusterRabbit1@VM235,clusterRabbit2@VM235]}]},
      {running_nodes,[clusterRabbit2@VM235,clusterRabbit1@VM235]},
      {partitions,[]}]
      ...done.
      

3. 集群中节点的关闭与重启
   1. 节点关闭并重启之后会选择一个在线的集群成员(只考虑磁盘节点)进行同步。在重新启动节点时，默认情况下将尝试与该成员联系10次，并有30秒的响应超时。如果该成员在时间间隔内可用则节点将成功启动，并与该成员同步所需内容后继续运行。如果该成员无法响应，则重新启动的节点将放弃同步数据并启动。
   2. 以下情况将导致节点无法重新加入集群：
   • 修改节点名/主机名，节点的数据目录路径会因此更改。
   • 重置节点数据/更换节点数据目录
4. 移除集群中的节点
   1. 关闭该节点
   2. 重置该节点
   3. 再次启动该节点

四、集群测试

1. 创建用户、vhost、exchange、queue，并启动消费者。【测试基础】
   1. 用户：api_management（management标签，开放虚拟主机cluster所有权限）
   2. vhost：cluster
   3. exchange：cluster（直连交换机）
   4. queue：
      1. 节点一 clusterRabbit1：
         1. 队列一：
         • name：clusterRabbit1Queue1
         • routing_key：clusterRabbit1key
         1. 队列二：
         • name：clusterRabbit1Queue2
         • routing_key：clusterRabbitCommonKey
      2. 节点二 clusterRabbit2：
         1. 队列三：
         • name：clusterRabbit2Queue1
         • routing_key：clusterRabbit2key
         1. 队列四：
         • name：clusterRabbit2Queue2
         • routing_key：clusterRabbitCommonKey（与队列二 相同）
   5. consumer：
      1. 消费者一：
      • 连接节点：节点一 clusterRabbit1
      • 消费队列：队列一 clusterRabbit1Queue1
        1. 消费者二：
      • 连接节点：节点一 clusterRabbit1
      • 消费队列：队列二 clusterRabbit1Queue2
        1. 消费者三（非此节点的队列）：
      • 连接节点：节点一 clusterRabbit1
      • 消费队列：队列三 clusterRabbit2Queue1
        1. 消费者四：
      • 连接节点：节点二 clusterRabbit2
      • 消费队列：队列四 clusterRabbit2Queue2
2. 连接节点二 clusterRabbit2,再次声明队列名和队列一同名的队列clusterRabbit1Queue1。【同名队列再次声明】
   • 结果：声明不成功，节点二中没有生成新的clusterRabbit1Queue1队列，而节点一中clusterRabbit1Queue1队列多出了新绑定的routing_key,这意味着在同一集群中不同节点之间的队列名是唯一的,在一个节点中可以操作另一个节点的队列数据。
3. 生产者连接节点一 clusterRabbit1，发布clusterRabbit1key消息。【发布此节点队列消息】
   • 消费者一 成功接收到消息
4. 生产者连接节点二 clusterRabbit2，发布clusterRabbit1key消息。【发布非此节点队列消息】
   • 消费者一 成功接收到消息
5. 生产者连接节点一 clusterRabbit1，发布clusterRabbitCommonKey消息。【多个节点队列绑定相同消息】
   • 消费者二 成功接收到消息
   • 消费者四 成功接收到消息
6. 生产者连接节点一 clusterRabbit1，发布clusterRabbit2key消息。【消费非此节点队列消息】
   • 消费三 成功接收到消息
7. 关闭节点二 clusterRabbit2，连接节点一，发布clusterRabbit2key消息【投递消息给集群中意外退出的节点】
   • 关闭节点二 clusterRabbit2之后，消费者三、四异常退出
   • 投递消息至集群成功
   • 再次启动节点二 clusterRabbit2以及消费者三、四，之前投递的消息没有成功接收

五、使用总结

1. 同一集群中不同节点之间的队列名是唯一的，在一个节点中可以操作另一个节点的队列数据。
2. 生产者可以发布集群中任一节点队列绑定的消息，集群将自动匹配出符合条件的节点队列，并投递给消费者进行消费。
3. 集群中不同节点的队列如果绑定了相同的routing_key，消息将投递到集群中所有符合路由匹配条件的节点队列中。
4. 消费者可以订阅集群中任意节点的队列。
5. 集群中某个节点异常退出后，生产者投递到集群中的消息将无法送达至该节点，但是不影响其他节点的接收。（解决这个问题需要使用镜像队列集群）

六、错误记录

1. 启动新的节点报错：could_not_start,rabbitmq_management

   解决：

   ​ rabbitmq_management插件默认使用的是15672端口，这个端口已被之前启动的节点占用，修改启动命名为 rabbitmq_management插件指定一个新的端口即可。

   RABBITMQ_NODE_PORT=5674 RABBITMQ_NODE_IPDDRESS=192.168.0.235  RABBITMQ_SERVER_START_ARGS="-rabbitmq_management listener [{port,15673}]" RABBITMQ_NODENAME="clusterRabbit1@VM235"  /usr/local/rabbitmq/3.1.3/sbin/rabbitmq-server -detached
   

2. 【认知错误】rabbitmq_management管理后台Overview中节点的Memory表示使用的内存，Disk space表示剩余可用的磁盘空间，不是已使用的磁盘空间。

3. 修改节点的host后启动失败:``ERROR: epmd error for host "VM235": nxdomain (non-existing domain)`

   解决：

   ​ VM235需要预先添加到 HOST文件，确保可以被正确解析。

4. 节点一 clusterRabbit1 退出集群后重新加入集群，再次声明之前的队列提示routing_key绑定不成功

   NOT_FOUND - no binding clusterRabbitCommonKey between exchange 'cluster' in vhost 'cluster' and queue 'clusterRabbit1Queue2' in vhost 'cluster'
   

   此问题是rabbitMq集群本身的问题，且未得到官方明确的解决方案。

   一些临时解放方案：

• 修改节点一名称
• 删除并重建交换机

• 修改旧的队列名或者队列参数

  根本解决：

  ​ 升级rabbitMq至3.8.0，参考【RabbitMq 使用docker搭建集群篇】。