RabbitMQ集群形成和要求

1、集群形成要求

1.1、主机名解析

RabbitMQ节点使用域名相互寻址。
因此，所有集群成员的主机名必须满足：

• 可以从所有集群节点进行解析
• 可以使用rabbitmqctl命令行工具进行解析

1.2、端口访问

RabbitMQ节点服务必须绑定到端口（服务端 TCP 套接字）以接受客户端和 CLI（英语：command-line interface，命令行接口）工具连接。
确保可以访问以下常用端口：

• 5672：AMQP使用。
• 15672：HTTP API客户端、web管理界面使用。
• 25672：用于节点间和 CLI 工具通信（Erlang 分发服务器端口）并从动态范围分配（计算方式：AMQP端口+20000）。除非确实需要这些端口上的外部连接，否则不应公开这些端口。
  35672~35682：由 CLI 工具（Erlang 分发客户端端口）用于与节点通信，并从动态范围（计算方式：服务器分发端口 + 10000 ~ 服务器分发端口 + 10010）分配。

1.3、集群中的节点

集群的组成可以动态改变。所有 RabbitMQ 代理开始时都在单个节点上运行。这些节点可以加入集群，然后再次变回单个代理。

节点名称（标识符）
RabbitMQ 节点是由节点名称标识，并且也是根据节点名称存储数据。节点名称由两部分组成，默认前缀rabbit和主机名。例如，rabbit@my_rabbitmq1 是一个带有rabbit前缀和my_rabbitmq1主机名的节点名称。

这对于在 Docker 中的使用应该为每个守护进程明确指定 --hostname 以便我们不会获得随机的主机名并可以跟踪我们的数据。

集群中的节点名称必须是唯一的。如果在给定主机上运行多个节点，则它们必须使用不同的前缀，例如rabbit1@hostname和rabbit2@hostname。

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

当一个节点启动时，它会检查它是否已经被分配了一个节点名称。这是通过RABBITMQ_NODENAME 环境变量完成的。如果没有显式配置值，则节点解析其主机名并在其前面添加rabbit以计算其节点名称。

内存限制
RabbitMQ 包含跟踪和管理内存使用的功能。
相关配置是rabbitmq.conf中的vm_memory_high_watermark。如果设置相对限制vm_memory_high_watermark.relative，则RabbitMQ将根据主机的总内存而不是由 docker容器 运行时设置的限制来计算其限制。

1.3.1、复制

RabbitMQ 代理操作所需的所有数据和状态都可在所有节点之间进行复制，但是 消息队列 除外，消息队列默认驻留在一个节点上，尽管它们对所有节点都是可见和可访问的。

1.3.2、节点是平等的

一些分布式系统节点具有领导者和追随者的概念。对于 RabbitMQ 来说，这通常是不存在的。RabbitMQ 集群中的所有节点都是对等的：RabbitMQ 核心中没有特殊节点，所有集群节点都被视为平等（CLI 工具操作可以针对任何节点执行、一个HTTP API客户端可以针对任何群集节点进行操作）。

单个插件可以在一段时间内指定（选举）某些节点为“特殊”节点。例如，联合链接 位于特定的集群节点上。如果该节点出现故障，链接将在不同的节点上重新启动。

1.3.3、CLI 工具如何对节点（以及节点彼此）进行身份验证：Erlang Cookie

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

如果该cookie文件不存在，Erlang VM 会在 RabbitMQ 服务器启动时尝试创建一个随机生成的值。使用此类生成的 cookie 文件仅适用于开发环境。由于每个节点都会独立产生自己的价值，这种策略在集群环境中不可行。

Erlang cookie 生成应该在集群部署阶段完成，最好使用自动化和编排工具。

在分布式部署中，Cookie 文件位置：

• 在Linux、MacOS系统上，cookie
  通常位于/var/lib/rabbitmq/.erlang.cookie（由服务器使用）和$HOME/.erlang.cookie（由CLI 工具使用）。 请注意，由于$HOME的值因用户而异，因此有必要为使用 CLI 工具的每个用户放置 cookie 文件的副本。
• 在docker镜像版中，使用RABBITMQ_ERLANG_COOKIE环境变量值来填充 cookie 文件。使用镜像的配置管理和容器编排工具必须确保集群中的每个 RabbitMQ 节点容器都使用相同的cookie值。
  RabbitMQ 节点将在启动初期记录其有效用户的主目录位置。
• 在 Windows 上，对于从 20.2 开始的 Erlang 版本，cookie 文件位置为：
  （1）如果HOMEDRIVE和HOMEPATH环境变量都设置了：
  %HOMEDRIVE%%HOMEPATH%.erlang.cookie（对于用户%USERNAME%通常是C:\Users%USERNAME%.erlang.cookie）
  （2）如果HOMEDRIVE和HOMEPATH都没有设置：%USERPROFILE%.erlang.cookie (通常是C:\Users%USERNAME%.erlang.cookie )
  （3）对于 RabbitMQ Windows 服务 - %USERPROFILE%.erlang.cookie（通常是C:\WINDOWS\system32\config\systemprofile）
  注意：如果使用 Windows 服务，则应将 cookie 从 C:\Windows\system32\config\systemprofile.erlang.cookie 复制到用户运行诸如rabbitmqctl.bat 之类的命令的预期位置。

1.3.4、认证失败

当 cookie 配置错误（例如，不相同）时，RabbitMQ 节点将记录错误，例如“来自不允许的节点的连接尝试”、“无法启动集群”。

例如，当 CLI 工具连接并尝试使用不匹配的秘密值进行身份验证时：

2021-10-15 13:03:33 [error] <0.1187.0> ** 来自节点“rabbitmqcli-99391-rabbit@warp10”的连接尝试被拒绝。无效的质询回复。**

错误放置的 cookie 文件或 cookie 值不匹配是此类故障的最常见情况。所以，出现认证失败的问题时（被远程节点拒绝），请检查Erlang cookie。

1.4、基于 Cookie 的身份验证故障排除

1.4.1、服务器节点

当一个节点启动时，它将记录其有效用户的主目录位置：

节点：rabbit@cdbf4de5f22d
主目录：/var/lib/rabbitmq

除非任何服务器目录被覆盖，否则将在该目录中查找 cookie 文件，并在节点首次启动时创建该目录（如果该目录尚不存在）。在上面的示例中，cookie 文件位置将是/var/lib/rabbitmq/.erlang.cookie。

1.4.2、主机名解析

由于主机名解析是节点间成功通信的先决条件，从RabbitMQ 3.8.6开始，CLI 工具提供了两个命令来帮助验证节点上的主机名解析是否按预期工作。

1.4.3、命令行工具

从版本3.8.6开始，rabbitmq-diagnostics包含一个命令，该命令提供有关 CLI 工具使用的 Erlang Cookie 文件的相关信息：

rabbitmq-diagnostics erlang_cookie_sources

该命令将报告有效用户、用户主目录和 cookie 文件的预期位置

1.5、节点计数和仲裁

由于几个特性（例如仲裁队列、MQTT 中的客户端跟踪）需要集群成员之间达成共识，因此强烈建议使用奇数个集群节点：1、3、5、7 等。

强烈建议不要使用两个节点集群，因为在连接丢失的情况下，集群节点不可能识别多数并形成共识。

1.6、集群和客户端

假设所有集群成员都可用，客户端可以连接到任何节点并执行任何操作。节点将对 客户端透明地将操作路由到 仲裁队列领导者或队列领导者副本。

对于所有支持的消息传递协议，客户端一次只能连接到一个节点。

如果节点发生故障，客户端应该能够重新连接到不同的节点，恢复其拓扑结构并继续操作。因此，大多数客户端库都接受端点列表（主机名或 IP 地址）作为连接选项。如果客户端支持，主机列表将在初始连接和连接恢复期间使用。

仲裁队列领导者：
仲裁队列是 RabbitMQ 的一种现代队列类型，它基于Raft 共识算法实现了一个持久的、复制的 FIFO 队列。它从 RabbitMQ 3.8.0 开始可用。
仲裁队列类型是持久镜像队列的替代方案， 专为数据安全是重中之重的一组用例而构建。这在动机 中有介绍。仲裁队列应被视为复制队列类型的默认选项。

队列领导者副本：
RabbitMQ 中的每个队列都有一个主副本。该副本称为 队列领导者（最初是“队列主控”）。所有队列操作首先通过leader副本，然后复制到follower（镜像）。这对于保证消息的 FIFO 排序是必要的。
为了避免集群中的某些节点托管大多数队列领导副本并因此处理大部分负载，队列领导应该合理地均匀分布在集群节点之间。

1.7、聚类和可观察性

客户端连接、通道和队列将分布在集群节点上。运营商需要能够跨所有集群节点检查和监控此类资源。

RabbitMQ CLI 工具（例如rabbitmq-diagnostics和rabbitmqctl）提供检查资源和集群范围状态的命令。一些命令关注单个节点的状态（例如rabbitmq-diagnostics environment和rabbitmq-diagnostics status），其他命令检查集群范围的状态。检查集群范围的状态的一些示例包括rabbitmqctl list_connections、 rabbitmqctl list_mqtt_connections、rabbitmqctl list_stomp_connections、rabbitmqctl list_users、 rabbitmqctl list_vhosts等。

这种“集群范围”的命令通常会首先联系一个节点，发现集群成员并联系他们全部以检索和组合他们各自的状态。例如， rabbitmqctl list_connections将联系所有节点，检索它们的 AMQP 连接，并将它们全部显示给用户。用户不必手动联系所有节点。假设集群的状态不变（例如，没有连接被关闭或打开），针对两个不同节点一个接一个执行的两个 CLI 命令将产生相同或语义相同的结果。然而，“节点本地”命令不会产生相同的结果，因为两个节点很少有相同的状态：至少它们的节点名称会不同！

管理 UI 的工作方式类似：必须响应 HTTP API 请求的节点将扇出到其他集群成员并聚合他们的响应。在具有多个启用管理插件的节点的集群中，操作员可以使用任何节点访问管理 UI。使用 HTTP API 收集有关集群状态的数据的监控工具也是如此。不需要依次向每个集群节点发出请求。

更加详细的使用请参考管理UI使用引导：https://www.rabbitmq.com/management.html

1.8、节点故障处理

RabbitMQ 代理可以容忍单个节点的故障。节点可以随意启动和停止，只要它们可以联系在关闭时已知的集群成员节点。

仲裁队列允许队列内容跨多个集群节点复制，只要大多数副本在线，并行复制和可预测的领导者选举 和数据安全行为。

非复制经典队列也可以在集群中使用。节点故障时的非镜像队列行为 取决于队列持久性。

RabbitMQ 集群有几种处理网络分区的模式，主要是面向一致性的。群集旨在跨 LAN （内网）使用。不建议运行跨 WAN （广域网）的集群。

1.9、指标和统计

每个节点都存储和聚合自己的指标和统计信息，并提供一个 API 供其他节点访问。一些统计数据是集群范围的，其他统计数据特定于单个节点。响应HTTP API请求的节点与其对等方联系以检索其数据，然后生成聚合结果。

在 1.6.7 之前的版本中，RabbitMQ 管理插件使用专用节点进行统计信息收集和聚合。

管理插件概述：
RabbitMQ 管理插件提供了一个基于 HTTP 的 API 来管理和监控 RabbitMQ 节点和集群，以及一个基于浏览器的 UI 和一个命令行工具rabbitmqadmin。它定期收集和汇总有关系统许多方面的数据。这些指标在 UI 和监控系统中向操作员公开，用于长期存储、警报、可视化、图表分析等。

参考：https://www.rabbitmq.com/clustering.html#cluster-formation