rabbitmq集群

为了简单就用三台服务器搭建,其中192.168.1.197为磁盘节点，其他服务器为内存节点，前面一篇文章说了rabbitmq的安装这里就直接讲配置了
主机1：192.168.1.197
主机2：192.168.1.111
主机3：192.168.1.160
1、在三台主机上分别修改host文件
vim /etc/hosts
加上以下内容

192.168.1.197 rabbit1
192.168.1.111 rabbit2
192.168.1.160 rabbit3

2、复制主机1的cookie 到主机2和主机3
Rabbitmq的集群是依赖于erlang的集群来工作的，所以必须先构建起erlang的集群环境。Erlang的集群中各节点是通过一个magic cookie来实现的，这个cookie存放在 /var/lib/rabbitmq/.erlang.cookie 中，文件是400的权限。所以必须保证各节点cookie保持一致，否则节点之间就无法通信

scp /var/lib/rabbitmq/.erlang.cookie root@192.168.1.111:/var/lib/rabbitmq/
scp /var/lib/rabbitmq/.erlang.cookie root@192.168.1.160:/var/lib/rabbitmq/

3、重启rabbitmq

systemctl restart rabbitmq-server.service

4、连接集群
在主机2和主机3上分别执行,其中--ram代表是内存节点，如果希望是磁盘节点则不用加--ram，在rabbitmq集群中，至少需要一个磁盘节点

rabbitmqctl stop_app
rabbitmqctl join_cluster --ram rabbit@rabbit1
rabbitmqctl start_app

5、查看集群

rabbitmqctl cluster_status

image.png

Rabbit模式大概分为以下三种：单主机模式、普通集群模式、镜像集群模式
单主机模式：

RabbitMQ服务运行在单独的一台主机中，通常生产环境不使用该模式，性能有限，并且如果服务器宕机服务将完全不可用。
普通集群模式

一说到集群问题瞬间变得复杂多了。首先对于Queue来说消息实体只存在于其中一个节点，集群中其他节点仅有相同的元数据，即队列结构。

当消息进入A节点的Queue中后，Consumer从B节点拉取消息时，RabbitMQ会临时在两个节点间进行消息传输，把A中的消息实体取出并经过B发送给Consumer。所以Consumer应尽量连接每一个节点，从中取消息。即对于同一个逻辑队列，要在多个节点建立Queue。否则Consumer如果只连接一个节点区消息会造成该节点的性能瓶颈。

该模式存在一个问题就是当其中一个节点故障后，其他节点无法取到故障节点中还未消费的消息。如果做了消息持久化，那么得等A节点恢复，然后才可被消费；如果没有持久化的话，那就杯具了！

镜像集群模式

前面讲到RabbitMQ的普通集群模式不同节点间只同步队列结构不同步消息。镜像模式会把队列结构和消息都存在于多个节点，属于RabbitMQ的HA方案。其实质和普通模式不同之处在于，消息实体会主动在镜像节点间同步。该模式带来的副作用也很明显，除了降低系统性能外，如果镜像队列数量过多，加之大量的消息进入，集群内部的网络带宽将会被这种同步通讯大量消耗。所以这种模式应用于可靠性要求较高的场合中。

配置镜像队列

rabbitmqctl set_policy ha-all "^ha\." '{"ha-mode":"all"}' //意思表示以ha.开头的queue都会复制到各个节点 ["^"匹配所有]

配置成功后在web界面可以看到

image.png

也可以通过web界面配置

image.png
查看
image.png

如果报以下错误，说明主机名没有切换，重启服务器即可

image.png

节点的一些操作
删除节点

rabbitmqctl stop_app
rabbitmqctl forget_cluster_node rabbit@rabbit2
 rabbitmqctl reset

一些重要的警告：
当整个集群关闭时，最后一个关闭的节点必须是第一个要联机的节点。
如果要脱机的最后一个节点无法恢复，可以使用forget_cluster_node命令将其从群集中删除
如果所有集群节点同时停止并且不受控制（例如断电），则可能会留下所有节点都认为其他节点在其后停止的情况。在这种情况下，您可以在一个节点上使用force_boot命令使其再次可引导