普通模式 ( 默认 ) :对于Queue来说,消息实体只存在于其中的一个节点,A/B两个节点仅有相同的元数据,即队列结构.(交换机的所有元数据在所有节点上是一致的,而队列的完整信息只有在创建它的节点上,各个节点仅有相同的元数据,即队列结构)当消息进入A节点的Queue中后,consumer从B节点拉取数据时,RabbitMQ会临时在A.B间进行消息传输,把A中的消息实体取出并经过B发送给consumer.所以consumer应尽量连接每个节点,从中取消息.即对于同一个逻辑队列,要在多个节点建立物理Queue,否则无论consumer连A或B,出口总在A,会产生瓶颈.该模式存在一个问题就是当A节点故障后,B节点无法取到A节点中还未消费的消息实体.如果做个消息持久化,那么等A几点恢复,然后才可被消费;如果没有做持久化,然后就...该模式非常适合非持久化队列,只有该队列是非持久化的,客户端才能重新连接到集群中的其他节点,并且重新创建队列,如果该队列是持久化的,那么唯一的办法就是将故障节点恢复起来.

镜像模式 ( 高可用模式 ): 把需要的队列做成镜像模式,存在于多个节点,数据Rabbitmq的HA方案.该模式解决了上述问题,其实质和普通模式的不同之处在于,消息实体会主动在镜像节点间同步,而不会在consumer取数据时临时拉取.该模式带来的副作用也很明显,除了降低系统性能意外,如果镜像队列过多,加之有大量的消息进入,集群内部的网络带宽将会被这种同步通讯大大消耗掉,所以在对可靠性要求较高的场合中适用.

镜像模式集群实现

1.安装2两台Linux操作系统并修改hostname 分别为A和B

2.关闭两个虚拟机的防火墙

3.执行vi /etc/hosts 文件内容如下

4.分别重启两台虚拟机

5. 在A中pingB，此时都可以ping通

6.在B中pingA，此时都可以ping通

安装 RabbitMQ

1.在2台Linux服务中分别安装RabbitMQ

详细安装方式

https://blog.csdn.net/weixin_59334478/article/details/127705429?spm=1001.2014.3001.5501

测试两台虚拟机是否安装成功

必须要保证2台Linux的Cookie 文件内容完全相同，可以选择使用vim进行编辑，也可以使用scp命令完成文件跨机器拷贝例如

[root@A ~]# scp /var/lib/rabbitmq/.erlang.cookie 192.168.115.132:/var/lib/rabbitmq

此时两台虚拟机里面的cookie都是一样的

注意：由于这个文件的权限是只读因此无论是使用 vim 还是 scp 来实现 Cookie 文件的同步都会失败，因此必须要修改这个文件的权限 ,

例如 chmod 777 /var/lib/rabbitmq/.erlang.cookie

当 Cookie 文件同步完成以后再修改权限回只读

例如 chmod 400 /var/lib/rabbitmq/.erlang.cookie

将某个RabbitMQ加入到某个服务器节点

rabbitmqctl stop_app

rabbitmqctl join_cluster rabbit@A

rabbitmqctl start_app

rabbitmqctl join_cluster rabbit@A 命令中的 A 为某个机器的 hostname ，在 hostname 为 B 的机器中执行这些命令

查看集群状态确认节点成功添加

进入两个虚拟机的控制台都可以看到两个节点

使用SpringBoot连接RabbitMQ集群

1.修改SpringBoot的application.properties文件进行集群的继承

2.运行消息生产者，发送消息

进入两个虚拟机控制台，查看控制台的消息

3.同样修改消息消费者的配置文件

4.运行消息消费者

通过控制台配置镜像：

把需要的队列做成镜像模式,存在于多个节点,数据Rabbitmq的HA方案.该模式解决了上述问题,其实质和普通模式的不同之处在于,消息实体会主动在镜像节点间同步,而不会在consumer取数据时临时拉取.该模式带来的副作用也很明显,除了降低系统性能意外,如果镜像队列过多,加之有大量的消息进入,集群内部的网络带宽将会被这种同步通讯大大消耗掉,所以在对可靠性要求较高的场合中适用.文件的同步都会失败，因此必须要修改这个文件的权限。此时两台虚拟机里面的cookie都是一样的。进入两个虚拟机控制台，查看控制台的消息。