大家好，今天小编来为大家解答rabbitmq服务器配置这个问题，rabbitmq需要开哪些端口很多人还不知道，现在让我们一起来看看吧！
一、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.
<!== 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 fet_cluster_node时，RabbitMQ将尝试为每个在我们忘记的节点上有其领导者的队列找到当前停止的镜像，并在它再次启动时“提升”该镜像成为新的领导者。如果有多个候选者，将选择最近停止的镜像。
重要的是要理解 RabbitMQ只能在 fet_cluster_node期间提升停止的镜像，因为任何再次启动的镜像都会清除它们的内容，如上面“停止节点和同步”中所述。因此在停止的集群中移除丢失的leader时，您必须在再次启动镜像之前调用 rabbitmqctl fet_cluster_node。
二、rabbitmq需要开哪些端口
RabbitMQ需要开启的端口有： 5672、15672、1883以及AMQP协议使用的默认端口如TCP协议默认使用437等动态分配的端口。具体的端口设置和数量也可能根据特定的RabbitMQ配置和需求有所不同。接下来对需要开启的端口进行详细的解释说明：
首先，RabbitMQ默认的通信端口是AMQP协议的默认端口，通常为TCP协议的端口号5672，这是RabbitMQ服务主要的通信端口，用于接收和发送消息。这是大多数场景下必须开启的端口。
其次，为了管理界面访问，RabbitMQ提供了一个管理插件，该插件默认运行在TCP端口15672上。这个端口用于访问RabbitMQ的管理界面，可以查看队列状态、*机状态等信息。如果需要使用管理插件，这个端口也需要开启。
另外，MQTT协议也常与RabbitMQ结合使用，特别是当RabbitMQ作为MQTT的代理服务器时，它会使用到MQTT协议默认的端口号，如TCP协议的端口号8883等。这需要确保防火墙或其他网络设备允许这些端口通过流量。对于支持动态分配AMQP协议的RabbitMQ集群配置来说，可能会有额外的网络端口需要开启来支持节点间的通信和数据*。但这通常是动态的、不固定的。另外如果采用其他的通信协议如STOMP或者MQTT时也会有不同的端口要求。如果需要对特定环境或需求进行详细配置和优化时，具体要开启哪些端口需要根据具体的配置和需求来确定。
最后，为了确保RabbitMQ的正常运行和通信顺畅，需要根据具体的部署环境和业务需求来配置和开放必要的端口，并确认相关的安全策略已经得到妥善处理，以保证数据传输的安全*和稳定*。此外还要注意监控和维护这些开放端口的状态和安全*。总之确保需要的端口已开启并且处于安全的环境中是保障RabbitMQ服务正常运行的关键之一。
三、RabbitMQ状态一直是Idle是怎么回事
要将RabbitMQ的状态从Idle（空闲）变为Running（运行），可以按照以下步骤进行操作：
1.检查RabbitMQ服务是否已启动：首先，确保RabbitMQ服务已经成功启动。您可以在操作系统的服务管理器中查找RabbitMQ服务，并确保其处于运行状态。
2.检查RabbitMQ配置文件：打开RabbitMQ的配置文件，通常是位于/etc/rabbitmq目录下的rabbitmq.config文件（Linux系统）或%APPDATA%\RabbitMQ目录下的rabbitmq.conf文件（Windows系统）。检查配置文件中的相关设置，确保配置正确并与您的需求相匹配。例如，您可能需要检查端口号、虚拟主机、用户名和密码等设置。
3.检查网络连接：确保RabbitMQ服务器可以被访问和连接。检查防火墙设置、网络连接以及消息传递环节是否正常，确保客户端能够与RabbitMQ服务器进行通信。
4.检查日志文件：查看RabbitMQ服务器的日志文件，通常位于/var/log/rabbitmq/（Linux系统）或%APPDATA%\RabbitMQ\logs（Windows系统）目录下。检查日志文件中是否存在任何错误或警告信息，以帮助确定问题的根本原因。
5.重启RabbitMQ服务：如果以上步骤都没有解决问题，可以尝试重启RabbitMQ服务。在操作系统的服务管理器中，停止RabbitMQ服务，并等待一段时间后再启动它。这可能会清除一些临时问题并使RabbitMQ状态从Idle变为Running。
如果以上步骤都没有解决问题，您可能需要更详细地检查并分析RabbitMQ服务器的配置、日志和网络环境。在遇到复杂问题时，建议参考RabbitMQ官方文档或寻求RabbitMQ社区的帮助和支持。