集群是如何工作的？

先安装正常的集群后，通过Web界面，能看到有两个节点，但是发现所有的消息都创建在一个节点上，如果把这个节点停掉，消息会丢失，但是另一个节点会启动。这可不是我们要的高可用性。查了一下说明，决定先简单地通过Web界面来配置一下队列镜像。先登录到集群中任一台管理界面，在菜单上点击“Admin”，然后在右侧选择“Policies”，选择“Add/update a policy”。

以上面为例：virtual host可以选择需要同步的目录。Name自己填。Pattern是正则表达式，填“^”表示所有的消息，Apply to表示需要同步的内容，默认是交换器和消息队列，Priority优先级可暂时不管，Definition里前一段可在下面选择，后一段的内容可在对应条目后的问号里找到可选择值。里面有一些细节，在网上搜了一下，在这里找到一个说明，挺详细的。

配置好后，发现消息队列的镜像的确已经完成，如果停掉一台机器，消息也不会丢，但是问题在于，如果将一台停掉，在切换过程中需要花1至2分钟的时间，结果就是用户使用会中断。这和我理解的镜像功能可不一样。

尝试改变客户端的连接方式

会不会是因为Spring的配置原因呢？

决定还是尝试在前端加一个阿里云的SLB。保证前端只有一个虚拟的IP地址，这样在客户端就好像用单机版的MQ一样来使用。

发现这样SLB却是时断时续，telnet虚拟IP的5672，时断时续，直接telnet后端的两台服务器却是可以的。只好求助于阿里的客服，他们最后给的方案是

售后工程师 : 对于添加到负载均衡实例后端的ECS，原则上不需要进行特别的配置。如果针对关联到负载均衡4层（TCP协议）服务的Linux系统的ECS，如果发现无法正常访问，需要确保系统配置文件/etc/sysctl.conf的以下三项为0：
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0
并使用sysctl -p更新配置:

https://help.aliyun.com/knowledge_detail/55206.html

按上面所说，对应的服务器中conf文件中并没有net.ipv4.conf.eth0.rp_filter = 0这一行，因为我们有内网和外网，所以我加了两行，分别对应eth0和eth1，加上后，SLB的确好用了。在网上查了一下这个配置，说是Linux默认开启了反向路由检查（reverse-pathfiltering，或称反向过滤技术）导致的，比如说外面访问eth0的网卡，而网关在eth1上，又或者从eth0出的流量，而网关在eth1上，此时会检查到网关不在同一个网卡上导致出不去，进不来的问题。解决方法：关闭反向路由检查。而上面的配置，就是将这个功能关闭。

这时，客户端的连接和原来用单机时一样，但是，当我手动断电一台机器时，切换仍是需要近2分钟的中断时间。看来不是连接问题，而是RabbitMQ自己的集群方式决定的，网上说，它用的是主从方式，当主机中断时，从机会切换成主机，这个切换过程需要时间。但我用代码直接连两台机器都是可以的，如果它是主从模式的话，应该是互为主从。当然，这都不是问题，关键在于，切换过程中，从机升级为主机时，从机也不响应，这样，我们想象中，如果用SLB可以做一个负载均衡，即使切换会有中断，至少有一半的用户不受影响，这种情况就做不到了，只要有切换，大家都会不响应。

这里还涉及到一些具体的HA同步的策略配置，找了一下，这篇文章比较好地解释了配置的运作流程。而这篇文章则更清楚地说明了几个参数的意义。考虑到这些参数只是定义故障时，消息同步的方式，从简单的角度出发，还是用默认值好了。

另外，还有一个小细节就是，为了调试消息的流动情况，可以在服务器上使Tracing插件启用。

rabbitmq-plugins enable rabbitmq_tracing

启用后，在Web界面的Admin菜单，刷新一下，能看到右侧多了一个tracing栏，点进去，加一个trac，能看到上面多了一个log文件可以下载。这里可以看到具体的消息内容。

用三台集群，改为内存节点，会优化切换时的效果吗？

既然，消息队列在主从切换会总是会有代价，如果改成3台，理论上说，如果一台宕机，会在另两台中选择一个作为主队列，只要客户连接到的不是被宕的，被升级的，而是第3台，就不会有影响，这样至少减少了一部分客户受影响的概率。

另外，一个应用，连接MQ时，往往只有2个连接通道，尽管消息队列可以有成千上万，但是在集群中，这个成千上万的队列是不可能被平均分配的，只有连接才有负载均衡的意义。这样，这个集群其实主要不是提升性能，而只是一个热备而已。

再增加一台ECS，配置相同，为了省事，这次登录后先yum update一下，免得云安全中心总是提醒有漏洞。按顺序简单再记 下命令

yum update

//安装erlang
cd /etc/yum.repos.d
mv epel.repo epel.repo.bak
vi /etc/yum.repos.d/rabbitmq-erl.repo
yum install erlang

//安装rabbitMQ
rpm --import https://github.com/rabbitmq/signing-keys/releases/download/2.0/rabbitmq-release-signing-key.asc
wget -P /root "https://github.com/rabbitmq/rabbitmq-server/releases/download/v3.7.17/rabbitmq-server-3.7.17-1.el7.noarch.rpm"
cd /root
yum install rabbitmq-server-3.7.17-1.el7.noarch.rpm

//启动
chkconfig rabbitmq-server on
/sbin/service rabbitmq-server start
rabbitmqctl status

//打开Web管理插件
rabbitmqctl add_user xiben passwd
rabbitmqctl set_user_tags xiben administrator
rabbitmqctl set_permissions -p / xiben ".*" ".*" ".*"
rabbitmqctl delete_user guest
rabbitmqctl list_users
rabbitmq-plugins enable rabbitmq_management

这时用Web页面就能看了，这里有一点小问题，就是如果我复制几行代码，在CentOS里，只运行第一行，而不是我原来经历的每行都运行，这可能和我拷贝时选择的编辑器有关，我只好一行一行地复制。

再次这台机器加到集群中

service rabbitmq-server stop

//编辑cookie文件，将rabbitMQ01或02上此文件内的那串字串替换过来
vi /var/lib/rabbitmq/.erlang.cookie

//编辑三台机器的hosts文件
vi /var/hosts

//加入集群
service rabbitmq-server start
rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl join_cluster rabbit@rabbitMQ01
rabbitmqctl start_app

rabbitmqctl cluster_status

现在三台都在集群中了，都是磁盘节点，查看三台的状态，目前主要的消息都连接在MQ01上，我想把01和02设为内存节点，03为磁盘节点。

//将MQ02变成RAM节点
rabbitmqctl stop_app
rabbitmqctl change_cluster_node_type ram
rabbitmqctl start_app

然后在MQ01上运行相同的上面三行命令，能看到MQ01和MQ02都是RAM了，而MQ03是Disc。现在的情况是，MQ01和MQ02是内存节点，通过SLB向外服务，而MQ03是磁盘节点，只做备份，不参与负载均衡。

看了一下，当前几个连接都在02上，我试着对02强制关机，结果和原来一样，客户端还是停止响应，而且时间比原来只有两台仅磁盘方式的还长。看来，这种方案并不能达到我们想象的效果。所以决定还是把它拆了，用原来两台磁盘镜像吧。

先分别在01，02两台机器上将节点模式修改成磁盘

rabbitmqctl stop_app
rabbitmqctl change_cluster_node_type disc
rabbitmqctl start_app

然后回到03机上

rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl start_app

这时，在01、02机上，用web界面查看，集群只有两台了，而在03的Web界面，发现无法登录了，提醒用户密码错误，看来reset真的相当于硬件设备的重置了，原来配的用户密码什么都没有了。果然，回到03机上用rabbitmqctl list_users看一下用户，只有默认的guest了。在另两台机器上用rabbitmqctl cluster_status看，也只有两个节点了。