RabbitMQ 部署及配置详解(集群部署)_rabbitmq集群部署详解

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新大数据全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注大数据）

正文

• 25672：用于节点间和 CLI 工具通信（Erlang 分发服务器端口） 并且从动态范围分配（默认情况下仅限于单个端口， 计算为 AMQP 端口 + 20000）。除非这些端口上的外部连接确实是必要的（例如 群集使用联合身份验证或在子网外部的计算机上使用 CLI 工具）， 这些端口不应公开。有关详细信息，请参阅网络指南。

• 35672-35682：CLI 工具（Erlang 分发客户端端口）用于与节点通信 并从动态范围（计算为服务器分发端口 + 10000 到 服务器分发端口 + 10010）。

可以将 RabbitMQ 配置为使用不同的端口和特定的网络接口

对等节点

一些分布式系统 具有领导节点和从节点。对于 RabbitMQ 来说，通常并非如此。 RabbitMQ 集群中的所有节点都是平等的对等节点：RabbitMQ 核心中没有特殊的节点。 当仲裁队列和插件时，本主题变得更加微妙 被考虑在内，但出于大多数意图和目的， 应将所有群集节点视为相等

节点间的身份验证

RabbitMQ 节点和 CLI 工具（例如 rabbitmqctl）使用 cookie 以确定是否允许他们与 彼此。为了使两个节点能够通信，它们必须具有 同样的共享密钥称为 Erlang cookie。cookie只是一个字母数字字符的字符串，最大为 255 个字符。 它通常存储在本地文件中。该文件必须仅 所有者可访问（例如，具有 600 或类似的 UNIX 权限）。 每个群集节点必须具有相同的 Cookie。如果该文件不存在，Erlang VM 将尝试创建 一个在 RabbitMQ 服务器时随机生成的值 启动。在开发中使用此类生成的 cookie 文件是合适的 仅限环境。在 UNIX 系统上，cookie 通常为 位于 /var/lib/rabbitmq/.erlang.cookie

三、部署

1、启动独立节点

RabbitMQ CLI 工具（如 rabbitmq-diagnostics 和 rabbitmqctl）提供了检查资源和集群范围状态的命令。

通过重新配置现有 RabbitMQ 来设置集群 节点加入群集配置。因此，第一步 就是以正常方式在所有节点上启动 RabbitMQ：

# on rabbit1
rabbitmq-server -detached
# on rabbit2
rabbitmq-server -detached
# on rabbit3
rabbitmq-server -detached

这将创建三个独立的 RabbitMQ 代理， 每个节点上一个，如 cluster_status 命令所确认的那样：

# on rabbit1
rabbitmqctl cluster_status
# => Cluster status of node rabbit@rabbit1 ...
# => [{nodes,[{disc,[rabbit@rabbit1]}]},{running_nodes,[rabbit@rabbit1]}]
# => ...done.

# on rabbit2
rabbitmqctl cluster_status
# => Cluster status of node rabbit@rabbit2 ...
# => [{nodes,[{disc,[rabbit@rabbit2]}]},{running_nodes,[rabbit@rabbit2]}]
# => ...done.

# on rabbit3
rabbitmqctl cluster_status
# => Cluster status of node rabbit@rabbit3 ...
# => [{nodes,[{disc,[rabbit@rabbit3]}]},{running_nodes,[rabbit@rabbit3]}]
# => ...done.

从 rabbitmq-server shell 脚本启动的 RabbitMQ 代理的节点名称是 rabbit@shorthostname，其中 short 节点名称为小写（如rabbit@rabbit1， 以上）。在 Windows 上，如果使用 rabbitmq-server.bat 批处理文件，则短节点名称为大写（如 在rabbit@RABBIT1）。键入节点名称时， 大小写很重要，这些字符串必须完全匹配

2、创建集群

为了将集群中的三个节点链接起来，我们告诉 其中两个节点，例如rabbit@rabbit2和rabbit@rabbit3，加入 第三，说rabbit@rabbit1。在此之前，两者 新加入的成员必须重置。

我们首先在集群中加入rabbit@rabbit2 与rabbit@rabbit1。为此，在rabbit@rabbit2我们停止了 RabbitMQ 应用程序并加入rabbit@rabbit1集群，然后重新启动 RabbitMQ 应用程序。请注意， 必须先重置节点，然后才能加入现有群集。 重置节点会删除以前的所有资源和数据 存在于该节点上。这意味着节点不能成为成员 并同时保留其现有数据。当需要时， 使用蓝/绿部署策略或备份和还原是可用选项。

# on rabbit2
rabbitmqctl stop_app
# => Stopping node rabbit@rabbit2 ...done.

rabbitmqctl reset
# => Resetting node rabbit@rabbit2 ...

rabbitmqctl join_cluster rabbit@rabbit1
# => Clustering node rabbit@rabbit2 with [rabbit@rabbit1] ...done.

rabbitmqctl start_app
# => Starting node rabbit@rabbit2 ...done.

我们可以看到，两个节点通过 在任一节点上运行 cluster_status 命令：

# on rabbit1
rabbitmqctl cluster_status
# => Cluster status of node rabbit@rabbit1 ...
# => [{nodes,[{disc,[rabbit@rabbit1,rabbit@rabbit2]}]},
# =>  {running_nodes,[rabbit@rabbit2,rabbit@rabbit1]}]
# => ...done.

# on rabbit2
rabbitmqctl cluster_status
# => Cluster status of node rabbit@rabbit2 ...
# => [{nodes,[{disc,[rabbit@rabbit1,rabbit@rabbit2]}]},
# =>  {running_nodes,[rabbit@rabbit1,rabbit@rabbit2]}]
# => ...done.

现在我们加入rabbit@rabbit3到同一集群。步骤与上面的步骤相同，只是这次我们将集群到rabbit2，以证明选择集群到的节点无关紧要——只需提供一个在线节点就足够了，该节点将集群到指定节点所属的集群。

# on rabbit3
rabbitmqctl stop_app
# => Stopping node rabbit@rabbit3 ...done.

# on rabbit3
rabbitmqctl reset
# => Resetting node rabbit@rabbit3 ...

rabbitmqctl join_cluster rabbit@rabbit2
# => Clustering node rabbit@rabbit3 with rabbit@rabbit2 ...done.

rabbitmqctl start_app
# => Starting node rabbit@rabbit3 ...done.

我们可以看到，这三个节点通过 在任何节点上运行 cluster_status 命令：

# on rabbit1
rabbitmqctl cluster_status
# => Cluster status of node rabbit@rabbit1 ...
# => [{nodes,[{disc,[rabbit@rabbit1,rabbit@rabbit2,rabbit@rabbit3]}]},
# =>  {running_nodes,[rabbit@rabbit3,rabbit@rabbit2,rabbit@rabbit1]}]
# => ...done.

# on rabbit2
rabbitmqctl cluster_status
# => Cluster status of node rabbit@rabbit2 ...
# => [{nodes,[{disc,[rabbit@rabbit1,rabbit@rabbit2,rabbit@rabbit3]}]},
# =>  {running_nodes,[rabbit@rabbit3,rabbit@rabbit1,rabbit@rabbit2]}]
# => ...done.

# on rabbit3
rabbitmqctl cluster_status
# => Cluster status of node rabbit@rabbit3 ...
# => [{nodes,[{disc,[rabbit@rabbit3,rabbit@rabbit2,rabbit@rabbit1]}]},
# =>  {running_nodes,[rabbit@rabbit2,rabbit@rabbit1,rabbit@rabbit3]}]
# => ...done.

通过执行上述步骤，我们可以在集群运行时随时向集群添加新节点。

3、重新启动群集节点

已加入群集的节点可以随时停止。它们也可能出现故障或被操作系统终止。

通常，如果节点停止后大多数节点仍处于联机状态，这不会影响集群的其余部分，尽管集群的客户端连接分布、队列副本放置和负载分布会发生变化。

4、来自联机对等方的架构同步

重新启动的节点将在启动时同步来自其对等节点的架构和其他信息。在这个过程完成之前，节点将不会完全启动和运行。

因此，了解流程节点在停止和重新启动时所经历的过程非常重要。

停止节点在重新启动后选择要同步的联机群集成员（只考虑磁盘节点）。在重新启动时，节点将尝试默认联系该对等方10次，并有30秒的响应超时。

如果对等方在该时间间隔内可用，则节点成功启动，从对等方同步所需内容并继续运行。

如果对等节点不可用，则重新启动的节点将放弃并自动停止。这种情况可以通过日志中的超时（timeout_waiting_for_tables）警告消息来识别，这些消息最终会导致节点启动失败：

`2020-07-27 21:10:51.361 [warning] <0.269.0> Error while waiting for Mnesia tables: {timeout_waiting_for_tables,[rabbit@node2,rabbit@node1],[rabbit_durable_queue]}
2020-07-27 21:10:51.361 [info] <0.269.0> Waiting for Mnesia tables for 30000 ms, 1 retries left
2020-07-27 21:11:21.362 [warning] <0.269.0> Error while waiting for Mnesia tables: {timeout_waiting_for_tables,[rabbit@node2,rabbit@node1],[rabbit_durable_queue]}
2020-07-27 21:11:21.362 [info] <0.269.0> Waiting for Mnesia tables for 30000 ms, 0 retries left`

`2020-07-27 21:15:51.380 [info] <0.269.0> Waiting for Mnesia tables for 30000 ms, 1 retries left
2020-07-27 21:16:21.381 [warning] <0.269.0> Error while waiting for Mnesia tables: {timeout_waiting_for_tables,[rabbit@node2,rabbit@node1],[rabbit_user,rabbit_user_permission, …]}
2020-07-27 21:16:21.381 [info] <0.269.0> Waiting for Mnesia tables for 30000 ms, 0 retries left
2020-07-27 21:16:51.393 [info] <0.44.0> Application mnesia exited with reason: stopped`

`2020-07-27 21:16:51.397 [error] <0.269.0> BOOT FAILED
2020-07-27 21:16:51.397 [error] <0.269.0> ===========
2020-07-27 21:16:51.397 [error] <0.269.0> Timeout contacting cluster nodes: [rabbit@node1].`

当节点在关闭期间没有联机对等端时，它将在不尝试与任何已知对等端同步的情况下启动。然而，它并不是作为一个独立的节点启动的，对等节点将能够重新加入它。

因此，当整个集群关闭时，最后一个关闭的节点是唯一一个在关闭时没有任何正在运行的对等节点的节点。该节点可以在不首先联系任何对等方的情况下启动。由于节点将尝试与已知对等方联系长达5分钟（默认情况下），因此可以在这段时间内以任何顺序重新启动节点。在这种情况下，他们将成功地一个接一个地重新加入对方。此时间窗口可以使用两种配置设置进行调整：

`# wait for 60 seconds instead of 30
mnesia_table_loading_retry_timeout = 60000

# retry 15 times instead of 10
mnesia_table_loading_retry_limit = 15`

通过调整这些设置和调整已知对等方必须返回的时间窗口，可以考虑到可能需要5分钟以上才能完成的集群范围内的重新部署场景。

在升级过程中，有时最后一个停止的节点必须是升级后第一个启动的节点。该节点将被指定执行集群范围的模式迁移，其他节点可以从该迁移同步并在重新加入时应用。

5、重新启动和运行状况检查（就绪探测器）

在某些环境中，通过指定的运行状况检查来控制节点的重新启动。检查验证一个节点是否已启动，并且部署过程可以继续到下一个节点。如果检查不通过，则认为节点的部署不完整，部署过程通常会等待一段时间并重试。这种环境的一个流行例子是Kubernetes，在这里，当使用OrderedReady pod管理策略时，操作员定义的就绪探测可以阻止部署继续进行。使用并行吊舱管理策略的部署不会受到影响，但必须担心初始集群形成期间的自然竞争条件。

考虑到上述对等同步行为，这样的健康检查可能会阻止集群范围内的重新启动及时完成。显式或隐式地假设重新加入其群集对等体的完全启动节点将失败并阻止进一步的节点部署的检查。

大多数健康检查，甚至是相对基本的健康检查，都隐含地假设节点已经完成引导。它们不适用于正在等待来自对等方的架构表同步的节点。

这种检查的一个非常常见的例子：

`# will exit with an error for the nodes that are currently waiting for
# a peer to sync schema tables from
rabbitmq-diagnostics check_running`

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注大数据）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

agnostics check_running`

**网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**

**需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注大数据）**
[外链图片转存中...(img-yduJZTdb-1713320010331)]

**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**