rabbitmq集群（六、rancher搭建rabbitmq集群化部署）

本文目录

• 六、rancher搭建rabbitmq集群化部署
• RabbitMQ集群恢复与故障转移的5种解决方案
• RabbitMQ分布式部署方案简介
• 详解RabbitMQ集群原理，值得收藏
• Ubuntu16.04搭建rabbitmq集群
• RabbitMQ集群
• RabbitMQ 进阶- 阿里云服务器部署RabbitMQ集群
• 【rabbitMQ】rabbitMQ集群节点重新加入集群相关操作
• windows下rabbitmq集群搭建

六、rancher搭建rabbitmq集群化部署

一．Rabbitmq在rancher上面部署
Prod：

这里要做3个rabbitmq，取名分别prod，master，slave
Master和slave基本配置一样，就是映射时候记得改一下映射文件名字就行下面是
master：

二．Rabbitmq在rancher添加服务如图：

Slave:

三．Rabbitmq的配置命令如图：
如果执行失败说明你没给容器设置容器名字

如果成功如图日志会打印：

四：Rabbitmq整合对外端口外加测试是否成功

到这里启动会报错说找不到配置为文件
现在我们要配置这个统一管理配置文件，记得改成你自己的服务名字：

RabbitMQ集群恢复与故障转移的5种解决方案

前提：比如两个节点A和B组成一个镜像队列

场景1： A先停， B后停
方案1： 该场景下B是Master，只要先启动B，再启动A即可。或者先启动A，再30秒之内启动B接口恢复镜像队列

场景2： A、B同时停机
方案2：该场景可能由于机房断电等原因造成的，只需在30秒之内连续启动A和B即可恢复镜像

场景3：A先停，B后停，且A无法恢复
方案3： 该场景是1场景的加强版，因为B是Master，所以等B起来以后，在B节点调用控制台命令： rabbitmqctl forget_cluster_node A 解除与A的Cluster关系，再将新的Slave节点加入B即可重新恢复镜像队列

场景4： A先停，B后停，且B无法恢复
方案4：该场景是场景3的加强版，比较难处理，原因是因为Master节点无法恢复，早在3.1x时代之前没有什么好的解决方案，但是现在已经有解决方案了，在3.4.2以后的版本。因为B是主节点，所有直接启动A是不行的，当A无法启动的时候，也就没办法在A节点上调用之前的 rabbitmqctl forget_cluster_node B 命令了。新版本中 forget_cluster_node 支持--offline参数

这就意味着允许rabbitmqctl在理想节点上执行该命令，迫使RabbitMQ在未启动Slave节点中选择一个节点作为Master。当在A节点执行 rabbitmqctl forget_cluster_node --offline B 时，RabbitMQ会mock一个节点代表A，执行 forget_cluster_node 命令将B剔除cluster，然后A就可以正常的启动了，最后将新的Slave节点加入A即可恢复镜像队列

场景5：A先停、B后停，且A、B均无法恢复，但是能得到A或B的磁盘文件
方案5：这种场景更加难处理，只能通过恢复数据的方式去尝试恢复，将A与B的数据文件模式在$RABBIT_HOME/var/lib/目录中，把它拷贝到新的节点对应的mulxia，再将新的节点hostname改成A或B的hostname，如果是A节点（Slave）的磁盘文件，则按照场景4处理即可，如果是B节点（Master）的磁盘文件，则按照场景3处理即可，最后新的Slave加入新节点后完成恢复。

场景6：A先停、B后停，且A、B均无法恢复，且得不到A和B的磁盘文件

恩，你可以直接跑路了o(╯□╰)o

RabbitMQ分布式部署方案简介

当单台RabbitMQ的性能不能满足我们的要求时，我们需要对其进行分布式部署，官方提供了三种方式来实现RabbitMQ的分布式部署，他们之间可以多种组合共同部署，我们分别介绍下

这种方式属于原生的“集群”，该种方式在逻辑上将多台机器联合到一起，对外只相当于一个broker，集群中的所有机器必须运行RabbitMQ和Erlang的相同版本。除了queue以外所有的数据将在集群中复制，queue默认只驻留在一个节点上，但是连接到集群中任何节点的client都可以看到集群中的所有队列，即使它们不在该节点上。要使队列实现高可用，可以使用镜像队列。使用镜像集群的缺点就是节点之间要传输大量的数据。

不像其他软件的集群方案，RabbitMQ集群中节点之间没有主从节点之分。

这种方式利用插件的机制实现集群，它的目标是不通过集群在broker之间传递消息，俩个broker可以有不同的 virtual hosts和用户，也可以运行在不同版本的RabbitMQ和Erlang上，broker之间通过AMQP协议进行通讯。Federation使exchange和queue联合起来，Federation exchange和 Federation queue可以从其他broker上的exchanges和queues接收消息。Federation exchange可以将消息路由到本地的queue，Federation queue允许本地消费者从其他broker获取消息。

它也是利用插件的机制实现集群，它将消息可靠的从broker中的queue移动到broker中的exchange，源和目的的broker可以相同或者不同，与Federation类似，使用WAN连接，broker可以运行在不同的Erlang与RabbitMQ版本上，连功能都大致相同，只不过Shovel相比于Federation粒度更细。

由于Federation和Shovel类似，这里把他俩归为一类。

Federation/Shovel ：每个broker在逻辑上是独立的；每个节点可以运行在不同的Erlang和RabbitMQ版本；broker之间通过广域网进行连接，消息传递使用AMQP协议；broker之间可以以各种拓扑形式连接，连接可以是双向或者单向；在CAP理论中更侧重于A（可用性）P（分区容错性）；连接到集群中的一个节点只能看见该节点上的queue。

Clustering： 逻辑上是相当于一个broker；每个节点Erlang和RabbitMQ版本必须相同；broker之间通过LAN连接，broker之间的消息传递使用Erlang；在CAP理论中侧重于C（一致性）P（分区容错性）；连接到其中一个节点即可看到所有节点上的queue。

***隐藏网址***

详解RabbitMQ集群原理，值得收藏

一般来说，如果只是为了学习RabbitMQ或者验证业务工程的正确性那么在本地环境或者测试环境上使用其单实例部署就可以了，但是出于MQ中间件本身的可靠性、并发性、吞吐量和消息堆积能力等问题的考虑，在生产环境上一般都会考虑使用RabbitMQ的集群方案。

RabbitMQ本身是基于Erlang编写，Erlang语言天生具备分布式特性（通过同步Erlang集群各节点的erlang.cookie来实现）。因此，RabbitMQ天然支持集群。集群是保证可靠性的一种方式，同时可以通过水平扩展以达到增加消息吞吐量能力的目的。

下图为集群的示例：

上面图中采用三个节点组成了一个RabbitMQ的集群，Exchange A（交换器）的元数据信息在所有节点上是一致的，而Queue（存放消息的队列）的完整数据则只会存在于它所创建的那个节点上。，其他节点只知道这个queue的metadata信息和一个指向queue的owner node的指针。

RabbitMQ集群会始终同步四种类型的内部元数据：

因此，当用户访问其中任何一个RabbitMQ节点时，通过rabbitmqctl查询到的queue／user／exchange/vhost等信息都是相同的。

为何RabbitMQ集群仅采用元数据同步的方式?

RabbitMQ集群的工作原理图如下：

客户端直接连接队列所在节点

如果有一个消息生产者或者消息消费者通过amqp-client的客户端连接至节点1进行消息的发布或者订阅，那么此时的集群中的消息收发只与节点1相关。

客户端连接的是非队列数据所在节点

如果消息生产者所连接的是节点2或者节点3，此时队列1的完整数据不在该两个节点上，那么在发送消息过程中这两个节点主要起了一个路由转发作用，根据这两个节点上的元数据转发至节点1上，最终发送的消息还是会存储至节点1的队列1上。同样，如果消息消费者所连接的节点2或者节点3，那这两个节点也会作为路由节点起到转发作用，将会从节点1的队列1中拉取消息进行消费。

1. 磁盘节点

将配置信息和元信息存储在磁盘上（单节点系统必须是磁盘节点，否则每次重启RabbitMQ之后所有的系统配置信息都会丢失）。

2. 内存节点

将配置信息和元信息存储在内存中。性能是优于磁盘节点的。

RabbitMQ要求集群中至少有一个磁盘节点，当节点加入和离开集群时，必须通知磁盘节点（如果集群中唯一的磁盘节点崩溃了，则不能进行创建队列、创建交换器、创建绑定、添加用户、更改权限、添加和删除集群节点）。总之如果唯一磁盘的磁盘节点崩溃，集群是可以保持运行的，但不能更改任何东西。因此建议在集群中设置两个磁盘节点，只要一个可以，就能正常操作。

普通集群模式，并不保证队列的高可用性。尽管交换机、绑定这些可以复制到集群里的任何一个节点，但是队列内容不会复制。虽然该模式解决一项目组节点压力，但队列节点宕机直接导致该队列无法应用，只能等待重启。所以要想在队列节点宕机或故障也能正常应用，就要复制队列内容到集群里的每个节点，也就是必须要创建镜像队列。篇幅有限，RabbitMQ镜像队列原理只能后面再分享了，感兴趣的朋友可以关注下！

Ubuntu16.04搭建rabbitmq集群

1.1、什么是RabbitMQ？

RabbitMQ 是由 LShift 提供的一个 Advanced Message Queuing Protocol (AMQP) 的开源实现，由以高性能、健壮以及可伸缩性出名的 Erlang 写成，因此也是继承了这些优点。

1.2、什么是AMQP?

AMQP，即Advanced Message Queuing Protocol，高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。它从生产者接收消息并递送给消费者，在这个过程中，根据规则进行路由，缓存与持久化。

AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。

RabbitMQ是一个开源的AMQP实现，服务器端用Erlang语言编写，支持多种客户端，如： Python 、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX。用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。

1.3、RabbitMQ的基础概念

1.4、RabbitMQ的特性

2.1、环境：两台Ubuntu16.04主机
10.27.0.53 rabbitmq-1
10.27.0.130 rabbitmq-2

必须保证各个主机名之间可以ping通
2.2、安装Erlang

2.3、安装rabbitmq

2.4、安装完成后，验证一下服务是否正常

搭建好的rabbitmq默认是没有配置文件的，需要我们来手动添加

Rabbitmq的一些运行脚本存放在 /usr/sbin 下面

2.5、开启web管理插件

2.5.1、创建一个用户nova，并设置密码为123456

2.5.2、查看现有用户表

这个时候nova用户是不能访问web管理插件的，需要配置用户角色，用户角色可分为五类，超级管理员, 监控者, 策略制定者, 普通管理者以及其他。

可登陆管理控制台(启用management plugin的情况下)，可查看所有的信息，并且可以对用户，策略(policy)进行操作。

可登陆管理控制台(启用management plugin的情况下)，同时可以查看rabbitmq节点的相关信息(进程数，内存使用情况，磁盘使用情况等)

可登陆管理控制台(启用management plugin的情况下), 同时可以对policy进行管理。但无法查看节点的相关信息。

仅可登陆管理控制台(启用management plugin的情况下)，无法看到节点信息，也无法对策略进行管理。

无法登陆管理控制台，通常就是普通的生产者和消费者。

将nova添加到administrator用户组

此时的nova用户只能通过本地来登录其他的IP无法直接使用这个账号。所以需要对他进行授权，使用户nova /(可以访问虚拟主机) 中所有资源的配置、写、读权限以便管理其中的资源

查看用户授权

2.5.3、开启web管理插件并重启rabbitmq服务

以下为关闭插件命令

***隐藏网址***

3.1、从管理界面可以看到，此时只有一个节点rabbitmq-1，我们需要把rabbitmq-2加进来，rabbitmq-2按照步骤2进行一系列安装就可以。此处不再细说。

3.2、添加节点
两台主机上安装的 RabbitMQ 都保证都可以正常启动,才可以进行以下操作
3.2.1、设置不同节点间统一认证的Erlang Cookie
这里将 rabbitmq-1 的该文件复制到 rabbitmq-2由于这个文件权限是 400为方便传输，先修改权限，非必须操作，所以需要先修改rabbitmq-2中的该文件权限为 777

然后将rabbitmq-1中的该文件拷贝的rabbitmq-2中

最后将权限和所属用户/组修改回来

此时rabbitmq-2节点需要重启一下服务

注意事项
cookie在所有节点上必须完全一样，同步时一定要注意。
erlang是通过主机名来连接服务，必须保证各个主机名之间可以ping通。可以通过/etc/hosts来手工添加主机名和IP对应关系。如果主机名ping不通，rabbitmq服务启动会失败。

3.2.2、通过rabbitmqctl cluster_status命令，可以查看和个节点的状态，节点的名称是rabbit@shorthostname，
rabbitmq-1

rabbitmq-2

3.2.3
将两个节点组成集群
因为rabbitmq-server启动时，会一起启动节点和应用，它预先设置RabbitMQ应用为standalone模式。要将一个节点加入到现有的集群中，你需要停止这个应用并将节点设置为原始状态，然后就为加入集群准备好了。使用rabbitmqctl stop_app仅仅关闭应用。

将2加入1中

启动节点2的应用

如果要使用内存节点，则可以使用以下命令：其中–ram指的是作为内存节点,要是想做为磁盘节点的话,就不用加–ram这个参数了

集群配置好后，可以在 RabbitMQ 任意节点上执行 rabbitmqctl cluster_status 来查看是否集群配置成功。
Rabbitmq-1

Rabbitmq-2

同时在Web管理工具中也可以看到效果

上面配置RabbitMQ默认集群模式，但并不保证队列的高可用性，尽管交换机、绑定这些可以复制到集群里的任何一个节点，但是队列内容不会复制，虽然该模式解决一部分节点压力，但队列节点宕机直接导致该队列无法使用，只能等待重启，所以要想在队列节点宕机或故障也能正常使用，就要复制队列内容到集群里的每个节点，需要创建镜像队列。

镜像队列概念：镜像队列可以同步queue和message，当主queue挂掉，从queue中会有一个变为主queue来接替工作。镜像队列是基于普通的集群模式的,所以你还是得先配置普通集群,然后才能设置镜像队列。镜像队列设置后，会分一个主节点和多个从节点，如果主节点宕机，从节点会有一个选为主节点，原先的主节点起来后会变为从节点。queue和message虽然会存在所有镜像队列中，但客户端读取时不论物理面连接的主节点还是从节点，都是从主节点读取数据，然后主节点再将queue和message的状态同步给从节点，因此多个客户端连接不同的镜像队列不会产生同一message被多次接受的情况。

设置镜像队列策略
在普通集群的中任意节点启用策略，策略会自动同步到集群节点
命令格式

在任意一个节点上执行

集群重启
集群重启时，最后一个挂掉的节点应该第一个重启，如果因特殊原因（比如同时断电），而不知道哪个节点最后一个挂掉。可用以下方法重启：
先在一个节点上执行

在其他节点上执行

查看cluster状态是否正常（要在所有节点上查询）。

添加用户
***隐藏网址***
命令格式

删除用户
命令格式

修改密码
命令格式

用户授权
命令格式

该命令使用户nova /(可以访问虚拟主机) 中所有资源的配置、写、读权限以便管理其中的资源

查看用户授权
命令格式

查看当前用户列表
可以看到添加用户成功了，但不是administrator角色

添加角色
这里我们也将nova用户设置为administrator角色
命令格式

再次查看权限

清除权限信息
命令格式

***隐藏网址***

RabbitMQ集群

如果有一个消息生产者或者消息消费者通过amqp-client的客户端连接至节点1进行消息的发布或者订阅，那么此时的集群中的消息收发只与节点1相关。

如果消息生产者所连接的是节点2或者节点3，此时队列1的完整数据不在该两个节点上，那么在发送消息过程中这两个节点主要起了一个路由转发作用，根据这两个节点上的元数据转发至节点1上，最终发送的消息还是会存储至节点1的队列1上。

RabbitMQ 集群是一个或多个节点的逻辑分组，每个节点共享用户、虚拟主机、队列、交换器、绑定、运行时参数和其他分布式状态。

一些分布式系统 有leader和follower节点。 对于 RabbitMQ 来说， RabbitMQ集群中的所有节点都是平等的。

RabbitMQ 集群可以通过多种方式组成：

RabbitMQ 节点绑定到端口以接受客户端和 CLI 工具连接。其他进程和工具（例如 SELinux）可能会阻止 RabbitMQ 绑定到端口。发生这种情况时，节点将无法启动。

CLI工具、客户端库和 RabbitMQ 节点也会打开连接（客户端 TCP 套接字）。防火墙会阻止节点和 CLI 工具相互通信。确保可以访问以下端口：

RabbitMQ节点和 CLI 工具（例如 rabbitmqctl）使用 cookie 来确定它们是否被允许相互通信。为了让两个节点能够通信，它们必须具有相同的共享密钥，称为 Erlang cookie。cookie 只是一串最多 255 个字符的字母数字字符。 它通常存储在本地文件中。该文件必须只能由所有者访问（例如具有 600 或类似的 UNIX 权限）。每个集群节点必须具有相同的 cookie。

在 UNIX 系统上，cookie通常是位于/var/lib/rabbitmq/.erlang.cookie（由服务器使用）和$HOME/.erlang.cookie（由 CLI 工具使用）。

RabbitMQ 节点使用主机名相互寻址

《!== 所有主机执行 ==》

《!== 所有主机执行 ==》

《!== 所有主机执行 ==》

默认配置文件/usr/lib/rabbitmq/lib/rabbitmq_server-3.7.17/ebin/rabbit.app

《!== node01主机执行 ==》

《!== node02主机执行 ==》

《!== node03主机执行 ==》

《!== 所有主机执行 ==》

因RabbitMQ 集群元数据同步基于 cookie 共享方案实现

文件路径/var/lib/rabbitmq/.erlang.cookie

《!== node02、node03主机执行 ==》

《!== 任意主机执行 ==》

节点分为：磁盘节点及内存节点

RAM节点是一种特殊情况，可用于提高具有高队列、交换或绑定搅动的集群的性能。RAM节点不提供更高的消息速率。 官方建议在绝大多数情况下，仅使用磁盘节点。

如果一个集群中都是RAM节点，那么集群停止，将无法再次启动，并将丢失所有数据

官方提示：经典队列镜像将在未来版本中删除，考虑改用仲裁队列或非复制经典队列

每个镜像队列由一个领导副本和一个或多个镜像副本，leader被托管的节点成为leader节点。首先应用给定队列的所有操作 在队列的leader节点上，然后传播到镜像。

如果承载队列的leader节点出现故障，则只要已同步，最旧的镜像将升级为新的leader。根据队列镜像参数，也可以升级未同步的镜像。

队列通过策略启用了镜像，策略模式的说明如下：

每当队列的策略发生变化时，它都保持其现有的镜像尽可能适用新策略。

设置的镜像队列可以通过开启的网页的管理端Admin-》Policies，也可以通过命令。

管理端界面：

命令行：

为避免集群中的某个节点托管大多数leader队列，因此导致高负载，leader队列应合理均匀的分布在集群节点上。控制leader队列分布节点策略有三种，可以在rabbitmq.conf文件中定义queue_master_locator参数设置

修改节点策略可能会导致现有的leader队列没有在新的策略中，为了防止消息丢失，RabbitMQ会保留现有的leader直到至少另一个镜像已同步，一旦发生同步，消费者将与leader断开连接，需要重新连接。

如果leader故障，其他镜像升级为leader过程如下：

如果消费者使用 自动确认模式 ，那么消息可能会丢失。这与非镜像队列没有什么不同：代理认为消息一旦以自动确认模式发送给消费者，就会被确认。

如果客户端突然断开连接，则可能永远不会收到消息。在镜像队列的情况下，如果leader死亡，那些正在以 自动确认模式 发送给消费者的消息可能永远不会被这些客户端接收，并且不会被新leader重新排队。由于消费客户端连接到存活节点的可能性，消费者取消通知有助于识别此类事件何时发生。 当然，在实践中，如果数据安全性不如吞吐量重要，那么自动确认模式是可行的方法。

节点可以随时加入集群。 根据队列的配置，当节点加入集群时，队列可能会在新节点上添加镜像。 此时，新镜像将是空的：它不会包含队列中任何现有的内容。 这样的镜像将接收发布到队列的新消息，因此随着时间的推移将准确地表示镜像队列的尾部。 随着消息从镜像队列中排出，新镜像丢失消息的队列头部的大小将缩小，直到最终镜像的内容与leader的内容完全匹配。 在这一点上，镜像可以被认为是完全同步的。

新添加的镜像不提供添加镜像之前存在的队列内容的额外形式的冗余或可用性，除非队列已明确同步。 由于在发生明确同步时队列变得无响应，因此最好允许正在从中排出消息的活动队列自然同步，并且仅明确同步非活动队列。

启用自动队列镜像时，请考虑所涉及队列的预期磁盘数据集 。 具有庞大数据集（例如，数十 GB 或更多）的队列必须将其复制到新添加的镜像中，这会给集群资源（例如网络带宽和磁盘 I/O）带来很大的负载。

要查看镜像状态（是否同步）：

手动同步队列：

取消正在进行的同步：

如果你停止一个包含镜像队列leader的 RabbitMQ 节点，其他节点上的一些镜像将被提升为leader。 如果继续停止节点，那么将到达一个镜像队列不再有镜像的点：它仅存在于一个节点上，且该节点上它是leader。 如果它的最后一个剩余节点关闭，但是镜像队列被声明为持久的，那么队列中的持久消息将在该节点重新启动后继续存在。

然而，镜像目前无法知道它的队列内容是否已经偏离了它重新加入的leader。 因此，当一个镜像重新加入一个镜像队列时， 它会丢弃已经拥有的任何持久本地内容并开始为空 。

默认情况下，RabbitMQ 将拒绝leader节点在受控关闭（即明确停止 RabbitMQ 服务或关闭操作系统）时提升非同步镜像，以避免消息丢失； 相反，整个队列将关闭，就好像未同步的镜像不存在一样。

leader节点不受控制的关闭（即服务器或节点崩溃，或网络中断）仍将触发未同步镜像的提升。

如果您希望在所有情况下都让leader队列移动到未同步的镜像（即，您会选择队列的可用性而不是避免由于未同步的镜像升级而导致的消息丢失），那么将 ha-promote-on-shutdown 策略键设置为 always 而不是比它的默认值 when-synced 。

如果 ha-promote-on-failure 策略键设置为 when-synced ，则即使 ha-promote-on-shutdown 键设置为 always ，也不会提升未同步的镜像。 这意味着如果leader节点发生故障，队列将变得不可用，直到leader恢复。 如果leader队列永久丢失，队列将不可用，除非它被删除（这也将删除其所有内容）并重新声明。

当队列的所有镜像都关闭时，可能会丢失队列的leader。 在正常操作中，队列关闭的最后一个节点将成为leader，该节点在再次启动时仍然是leader（因为它可能收到了其他镜像没有看到的消息）。

但是，当您调用 rabbitmqctl forget_cluster_node 时，RabbitMQ 将尝试为每个在我们忘记的节点上有其领导者的队列找到当前停止的镜像，并在它再次启动时“提升”该镜像成为新的领导者。 如果有多个候选者，将选择最近停止的镜像。

重要的是要理解 RabbitMQ 只能在 forget_cluster_node 期间提升停止的镜像，因为任何再次启动的镜像都会清除它们的内容，如上面“停止节点和同步”中所述。 因此在停止的集群中移除丢失的leader时，您必须在再次启动镜像之前调用 rabbitmqctl forget_cluster_node 。

RabbitMQ 进阶- 阿里云服务器部署RabbitMQ集群

如果RabbitMQ集群只有一个broker节点，那么该节点的失效将导致整个服务临时性的不可用，并且可能会导致message的丢失（尤其是在非持久化message存储于非持久化queue中的时候）。可以将所有message都设置为持久化，并且使用持久化的queue，但是这样仍然无法避免由于缓存导致的问题：因为message在发送之后和被写入磁盘并执行fsync之间存在一个虽然短暂但是会产生问题的时间窗。通过publisher的confirm机制能够确保客户端知道哪些message已经存入磁盘，尽管如此，一般不希望遇到因单点故障导致服务不可用。

如果RabbitMQ集群是由多个broker节点构成的，那么从服务的整体可用性上来讲，该集群对于单点失效是有弹性的，但是同时也需要注意：尽管exchange和binding能够在单点失效问题上幸免于难，但是queue和其上持有的message却不行，这是因为queue及其内容仅仅存储于单个节点之上，所以一个节点的失效表现为其对应的queue不可用。

为了提高程序的吞吐量，保持消息的可靠性，一台机器挂了后，RabbitMQ能够正常生产，消费消息。

rabbitmq有三种模式：单机模式，普通集群模式，镜像集群模式

Demo级别的，一般只是本机测试玩玩而已，生产环境下不会用的。

在多台机器上启动多个rabbitmq实例，每个机器启动一个。
但是你创建的queue，只会放在一个rabbtimq实例上，但是每个实例都同步queue的元数据(存放含queue数据的真正实例位置)。消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从queue所在实例上拉取数据过来。

示意图

这种方式确实很麻烦，也不怎么好，没做到所谓的分布式，就是个普通集群。
普通集群的方式，确实达到了消息的高可用，但没办法保证可靠性，没做到分布式，简而言之，只是一个普通的集群。

这种模式，才是所谓的rabbitmq的高可用模式，跟普通集群模式不一样的是，你创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次你写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。

上图中每个节点有一个queue，生产者生产完毕数据后投递到指定交换机的队列，交换机的队列进行消息同步。

每个节点queue都有一个完整的rabbitmq节点，所以这种方式叫做镜像集群

好处： 任何一个节点宕机后，其它节点不受影响，正常使用

坏处：

确保机器中安装了Docker，若未安装，可看：【云原生】Docker入门 – 阿里云服务器Linux环境下安装Docker

查看拉取的镜像

成功运行

设置节点1

浏览器输入 您的ip地址:15673

再次测试即可成功~

File —》 New —》 Project —》 Maven —》 直接Next 进入下一步创建普通的Maven工程即可

创建一个默认的Maven聚合工程，将src文件夹删除，该工程就是一个Maven聚合工程

引入依赖如下：

在项目内，新建一个Moudle，rabbitmq-order-producer 默认Maven工程，下一步即可

在项目内，新建一个Moudle，rabbitmq-order-cousumer 默认Maven工程，下一步即可

Maven聚合工程创建完成图

Maven依赖图

自行手写MainApplication即可

创建完成！

编写完成！

启动消费者

交换机

=

15674

15675

成功消费数据！

已成功同步消息~

【rabbitMQ】rabbitMQ集群节点重新加入集群相关操作

rabbitMQ 架构为  rabbitMQ + keepalived  镜像模式。

rabbitmq01  192.168.1.101

rabbitmq01  192.168.1.102

vip 192.168.1.110  在rabbitmq02 上
现在 rabbitmq01 故障 ，起不来，队列数据同步rabbbit02 有问题。

解决方法是将rabbitmq01 这个故障节点从集群中剔除，然后重新加入。
在rabbitmq02  192.168.1.102服务器上

剔除rabbitmq01节点

# rabbitmqctl cluster_status

# rabbitmqctl  forget_cluster_node  rabbit@192-168-1-101

# rabbitmqctl cluster_status
 

在rabbitmq01  192.168.1.101服务器上
停止rabbitmq相关进程

# systemctl  stop rabbitmq-server

# ps aux | grep rabbit | grep -v grep | awk ‘{print $2}’| xargs kill -9
移除rabbitmq相关数据文件

# mkdir /kingdee/rabbitmqBackup

# mv  /var/lib/rabbitmq/*  /kingdee/rabbitmqBackup/
重新启动rabbitmq

# systemctl  start  rabbitmq-server

# ps aux | grep rabbit
创建rabbitMQ用户

# rabbitmqctl  add_user   mquser    rabbitMQ@123

注：此密码为安装时设置的rabbitMQ密码
# rabbitmqctl  list_users

# rabbitmqctl  set_user_tags   mquser    administrator

# rabbitmqctl  set_permissions   -p  /   mquser    ’.*’  ’.*’  ’.*’

# rabbitmqctl  stop_app
# rabbitmqctl  join_cluster   rabbit@192-168-1-102

# rabbitmqctl  cluster_status
# rabbitmqctl  start_app

# systemctl  start  keepalived
在rabbitmq02  192.168.1.102服务器上

添加策略同步策略

# rabbitmqctl   set_policy ha-all  "^"   ’{"ha-mode":"all","ha-sync-mode":"automatic"}’
RabbitMQ Cluster群集安装配置

***隐藏网址***
Network partition detected

Mnesia reports that this RabbitMQ cluster has experienced a network partition. 

There is a risk of losing data. Please read RabbitMQ documentation about network partitions and the possible solutions.

***隐藏网址***

windows下rabbitmq集群搭建

准备2台机器，例如：computera: 10.0.0.151   computerb:10.0.0.234  都安装erlang环境和rabbitmq服务,注意otp环境和rabbitmq服务必须版本一致，否则无法搭建集群

步骤：

1.将2台机器的.erlang.cookie都设置一致，rabbitmq依赖它进行集群通讯（windows目录下C:\Users\Administrator和C:\Windows）

C:\Windows\System32\config\systemprofile

2.修改2台机器的host文件配置

               10.0.0.151    computera

               10.0.0.234    computerb

3.

  在2台机器C:\Users\Administrator\AppData\Roaming\RabbitMQ目录下添加rabbitmq.config集群配置文件，注意以.符号结尾

例如：

.

  10.0.0.151机器在该目录下同时添加rabbitmq-env.conf配置文件
NODENAME=rabbit@computera

NODE_IP_ADDRESS=10.0.0.151

NODE_PORT=5672

RABBITMQ_MNESIA_BASE=C:\Users\Administrator\AppData\Roaming\RabbitMQ\db

RABBITMQ_LOG_BASE=C:\Users\Administrator\AppData\Roaming\RabbitMQ\log

  10.0.0.234机器将ip修改为10.0.0.234、nodename修改为：rabbit@computerb

4.在10.0.0.234机器运行

          rabbitmqctl stop_app

          rabbitmqctl reset

rabbitmqctl start_app

   在10.0.0.151机器运行

          rabbitmqctl stop_app

          rabbitmqctl reset

          rabbitmqctl join_cluster rabbit@computerb --ram

          然后启动rabbit服务查看集群状态

          rabbitmqctl start_app

         rabbitmqctl cluster_status