RabbitMQ工厂虚拟机集群可靠性测试报告

高可用集群架构

目前Centos7.9通过直接RPM包部署安装的版本最高支持到3.8.28，Erlang相应版本支持范围为23.2到24.2，也通过RPM包安装部署

压力测试

测试方案

模式：用户办公电脑JAVA程序模拟生产者和和消费者
测试分类：高信息大小（10KB）/正常业务模式信息大小（200B）
测试连接地址：rabbitmqlb1.mfg.tp-link.com
测试端口：5672/tcp
结果统计来源：RabbitMQ UI组件数据统计，折线图统计

压力测试统计结果

脑裂测试

方案：RabbitMQ集群三个几点都安装iptables防火墙（使用firewalld防火墙模拟脑裂失败），25672为RabbitMQ集群节点交互端口，二三节点关闭集群交互端口25672，一节点开放所有需要的端口，通过RabbitMQ UI管理界面以及Zabbix RabbitMQ插件告警来判断脑裂是否模拟成功，集群在搭建时已设置恢复策略为Autoheal，模拟正常业务场景下的消息发送，后回滚防火墙操作，观察集群恢复情况，查看各节点日志关于分区恢复的详情

防火墙处理结果

节点1

[root@rabbitmq1-mfg sysconfig]# iptables -nL
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:5672
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:4369
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:25672
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

节点2

[root@rabbitmq2-mfg ~]# iptables -nL
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:25672
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:15672
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

节点3

[root@rabbitmq3-mfg ~]# iptables -nL
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:25672
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:15672

RabbitMQ UI管理界面脑裂显示

集群节点Autoheal自动恢复相关日志

节点1

接收到了来自二节点的Autoheal请求，得知了一二节点是losers，三节点是Winner，同时也会收到Winner三节点的Autoheal请求，但此时这是第二个Autheal请求就会忽略（已处于自动恢复状态中），一节点关闭自身Rabbitmq进程

节点2

二节点接收到了来自三节点的Autoheal重启通知，会将通知传递给下一个需要重启的节点一，然后自身关闭Rabbitmq进程

节点3

节点三在选举中胜出成为Winner，会将Autoheal请求发送到Rabbitmq一二节点，等待一二节点都关闭完后再让一二节点依次重启加入集群

总结

初始集群中，所有的镜像队列的master队列都是由Rabbitmq1-mfg一节点对外提供服务，二三节点上的队列为slave队列同步一节点数据，在发生脑裂后恢复后，三节点的master升格为了master队列，一二节点的队列变为slave队列进行数据同步，其中master队列的选举依靠多维度数据进行评判：客户端连接数，剩余磁盘量，节点负载等，在集群发生脑裂的过程中，消息发送失败率为0%，保证了业务的连续性，在非极端情况下，数据也能保证恢复后的一致性