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

最新推荐文章于 2024-05-30 23:16:51 发布

2301_82241942

最新推荐文章于 2024-05-30 23:16:51 发布

阅读量1k

点赞数 17

分类专栏： 2024年程序员学习文章标签： rabbitmq ruby linux

本文链接：https://blog.csdn.net/2301_82241942/article/details/137659650

版权

2024年程序员学习专栏收录该内容

59 篇文章 0 订阅

订阅专栏

仲裁队列是 RabbitMQ 实现持久、基于Raft共识算法的复制FIFO队列。它从 RabbitMQ 3.8.0 开始可用。

仲裁队列和流取代了持久镜像队列，即原始队列复制的队列类型，现已弃用并计划删除。

仲裁队列针对数据安全性为重中之重。这在动机中有所介绍。仲裁队列应被视为复制队列类型的默认选项。

与传统镜像队列相比，仲裁队列在行为上也存在重要差异和一些限制，包括特定于工作负载的，例如，当使用者重复对同一消息重新排队时。另外仲裁队列支持死信交换 （DLX）。

仲裁队列和镜像队列差异

2、节点名称

RabbitMQ 节点由节点名称标识。节点名称由两部分组成，前缀（通常是兔子）和主机名。例如，rabbit@node1.messaging.svc.local 是一个节点名称，前缀为 rabbit，主机名为 node1.messaging.svc.local。

群集中的节点名称必须是唯一的。如果给定主机上正在运行多个节点（这通常在开发和 QA 环境中），他们必须使用不同的前缀，例如rabbit1@hostname和rabbit2@hostname。

在群集中，节点使用节点名称相互标识和联系。这意味着必须解析每个节点名称的主机名部分。CLI 工具还使用节点名称识别和寻址节点。

当节点启动时，它会检查是否已为其分配节点名称。这是完成的通过RABBITMQ_NODENAME环境变量。如果未显式配置任何值，节点解析其主机名，并将 Rabbit 附加到它以计算其节点名称。

如果系统使用完全限定域名（FQDN）作为主机名，RabbitMQ 节点并且必须将 CLI 工具配置为使用所谓的长节点名称。对于服务器节点，这是通过将RABBITMQ_USE_LONGNAME环境变量设置为 true 来完成的。

对于 CLI 工具，必须设置 RABBITMQ_USE_LONGNAME 或 --longnames 选项必须指定。

3、集群形成要求

主机名解析

RabbitMQ 节点使用节点名称（组合）相互寻址前缀和域名，可以是短的还是完全限定的（FQDN）。因此，每个集群成员都必须能够解析主机名对于所有其他集群成员，其自己的主机名也是如此作为可能使用 RabbitMQCTL 等命令行工具的计算机。节点将在节点引导时尽早执行主机名解析。在基于容器的环境中，主机名很重要在容器启动之前，解决方案已准备就绪。对于 Kubernetes 用户来说，这意味着 CoreDNS 的 DNS 缓存间隔值在 5-10 秒范围内。

主机名解析可以使用任何标准操作系统提供方法：

域名系统记录
本地主机文件（例如 /etc/hosts)

在限制性更强的环境中，DNS 记录或主机文件修改受到限制、无法或不想要的，erlang可以将 VM 配置为使用备用主机名解析方法，例如备用 DNS 服务器，本地文件、非标准主机文件位置或混合的方法。这些方法可以与标准操作系统主机名解析方法。要使用 FQDN，请参阅配置指南中的RABBITMQ_USE_LONGNAME。

端口访问

RabbitMQ 节点绑定到端口（开放服务器 TCP 套接字）以接受客户端和 CLI 工具连接。其他进程和工具（如 SELinux）可能会阻止 RabbitMQ 绑定到端口。当这种情况发生时，节点将无法启动。CLI 工具、客户端库和 RabbitMQ 节点也打开连接（客户端 TCP 套接字）。防火墙可以阻止节点和 CLI 工具相互通信。以下端口与群集中的节点间通信最相关：

4369：epmd，RabbitMQ 节点和 CLI 工具使用的帮助程序发现守护进程
6000 到 6500：由 RabbitMQ 流复制使用
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


**自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。**

**深知大多数大数据工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！**

**因此收集整理了一份《2024年大数据全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。**
![img](https://img-blog.csdnimg.cn/img_convert/6e4513d4a9e7220be6b76e0c9745ed32.png)
![img](https://img-blog.csdnimg.cn/img_convert/301c03cf134eba6b8263f95172a2783f.png)
![img](https://img-blog.csdnimg.cn/img_convert/34064422533e886a352b7051e659fc35.png)
![img](https://img-blog.csdnimg.cn/img_convert/54b766f4c2cd88e9234cf96cda8b0154.png)
![img](https://img-blog.csdnimg.cn/img_convert/9c46575bc262fe2b71cfff0564ef1315.png)

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

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

**如果你觉得这些内容对你有帮助，可以添加VX：vip204888 （备注大数据获取）**
![img](https://img-blog.csdnimg.cn/img_convert/d99307c1779657ff7b092e1f55f477b9.png)


[外链图片转存中...(img-J1owZxlb-1712857943074)]
[外链图片转存中...(img-utTifBc5-1712857943074)]

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

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

**如果你觉得这些内容对你有帮助，可以添加VX：vip204888 （备注大数据获取）**
[外链图片转存中...(img-5APCie95-1712857943075)]

2301_82241942

关注

17
点赞
踩
14

收藏

觉得还不错? 一键收藏
0
评论
RabbitMQ 部署及配置详解(集群部署)_rabbitmq集群部署详解

仲裁队列是 RabbitMQ 实现持久、基于的复制FIFO队列。它从 RabbitMQ 3.8.0 开始可用。仲裁队列和取代了持久镜像队列，即原始复制的队列类型，。仲裁为重中之重。这在动机中有所介绍。仲裁队列应被视为复制队列类型的默认选项。与传统镜像队列相比，仲裁队列在也存在重要差异和一些，包括特定于工作负载的，例如，当使用者时。另外。
复制链接

扫一扫