12. 消息队列-RabbitMQ-管理后台详解

princemilo

493人浏览 · 2026-03-27 09:56:54

princemilo · 2026-03-27 09:56:54 发布

文章目录

前言
一、Overview
- 1.1. Totals
- 1.2. Nodes
二、Connections
三、Channels
四、Exchanges
五、Queues
- 5.1. 创建队列queue
六、Admin
- 6.1. 用户
- 6.2. 虚拟主机

前言

RabbitMQ管理后台‌

RabbitMQ 的管理插件，它提供了一个 Web UI 来监控和管理 RabbitMQ 服务器。

一、Overview

概述

1.1. Totals

总计

概述

在这里插入图片描述

队列积压情况：Queued messages (队列消息)

这个折线图展示了队列中消息数量在过去一分钟内的变化。

图例含义：
- Ready (黄色/0)：就绪消息。指已经在队列中，等待被消费者拉取的消息。
- Unacked (蓝色/0)：未确认消息。指已经被消费者取走（Delivery），但消费者尚未发送 ACK（确认）的消息。
- Total (红色/0)：总消息数。Total = Ready + Unacked。
当前状态分析：
- 目前队列中总共有 0 条消息。
- 0 条消息处于 Unacked 状态。
结论：正常。如果Unacked > 0，说明当前有消费者正在处理消息，且处理速度可能跟不上生产速度，或者消费者处理时间较长，导致消息堆积在“已取出但未确认”的阶段。

生产端/消费端表现：Message rates (消息速率)

这组图表展示了消息在不同环节的吞吐量（每秒消息数）。

生产端表现 (Publish & Confirm) 反映了生产者（Producer）发送消息的情况。

1. Publish (发布速率 - 黄色/13/s)

含义：生产者向交换机发送消息的速率。
解读：当前系统每秒有 13 条 新消息产生。

2. Publisher confirm (发布确认速率 - 浅蓝/13/s)

含义：生产者开启 publisher confirms 机制后，收到 RabbitMQ 返回的“消息已接收”确认的速率。
解读：13/s 与 Publish 速率完全一致。这是一个好现象，说明生产者发送的消息 100% 被 RabbitMQ 成功接收，没有消息在传输过程中丢失。

结论：

生产稳定：生产速度保持在 13条/秒左右。
可靠性高：Publish 和 Confirm 数值完全一致，说明开启了 Publisher Confirms 机制，且所有消息都成功落盘或被交换机接收，没有消息丢失。

消费端表现 (Deliver & Ack)

3. Deliver (发送给消费者速率 - 红色/8.0/s)

含义：RabbitMQ 将消息推送给消费者的速率。
解读：每秒有 8.0 条 消息被发送给了消费者。

4. Consumer ack (消费者确认速率 - 紫色/8.0/s)

含义：消费者处理完消息后，向 RabbitMQ 发送“确认已处理”（ACK）的速率。
解读：8.0/s 与 Deliver 速率一致。说明消费者处理消息非常顺畅，没有发生消息积压在客户端未确认的情况（即 Unacked 没有持续增长）。

其他指标

Redelivered (0.00/s): 没有消息被重新投递。说明消费者处理非常稳定，没有报错或超时导致消息重回队列。
Unroutable (0.00/s): 没有无法路由的消息。说明 Exchange 到 Queue 的绑定关系正确，消息都找到了路径。
Disk write (13/s): 磁盘写入速率与生产速率一致，说明消息正在被持久化到磁盘（如果开启了持久化）。：

健康状况诊断

生产消费平衡：消费速率（20/s）明显高于生产速率（13/s）。这意味着 消费者处理能力大于生产者生成能力，系统负载是健康的，队列中无积压消息，即使产生理论上也会很快被消化。
手动确认：使用的是 manual ack，这意味着业务代码中显式地进行了 ACK 确认，这是保证数据不丢失的最佳实践。
消费拉取和确认的微小差异：Deliver (20) 和 Ack (19) 之间有细微差别，这通常是因为网络延迟或消费者处理需要几毫秒时间，属于正常现象。
如果存在 Unacked：虽然消费速率快，如果仍有 Unacked 消息。这通常是因为网络延迟或消费者正在处理这些消息（尚未执行到 basicAck 代码），属于正常现象。

总结：当前系统目前处于最佳状态。
RabbitMQ 集群运行非常健康，生产者发送的消息均被可靠接收，消费者的处理能力足以覆盖生产压力，且无消息丢失风险。

无积压：消费速度 > 生产速度。
无丢失：生产端确认率 100%。
无错误：没有重投（Redelivered）和路由失败（Unroutable）。
机制健全：使用了持久化（Disk write）和手动确认（Manual Ack）。

详解

Ready：待消费的消息总数。
Unacked：待应答的消息总数。
Total：总数 Ready+Unacked。
Publish： producter pub消息的速率。
Publisher confirm： broker确认pub消息的速率。
Deliver(manual ack)： customer手动确认的速率。
Deliver( auto ack)： customer自动确认的速率。
Consumer ack： customer正在确认的速率。
Redelivered：正在传递’redelivered’标志集的消息的速率。
Get (manual ack)：响应basic.get而要求确认的消息的传输速率。
Get (auto ack)：响应于basic.get而发送不需要确认的消息的速率。
Return：将basic.return发送给producter的速率。
Disk read： queue从磁盘读取消息的速率。
Disk write： queue从磁盘写入消息的速率。
Connections：client的tcp连接的总数。
Channels：通道的总数。
Exchange：交换器的总数。
Queues：队列的总数。
Consumers：消费者的总数。

1.2. Nodes

节点

启动一个broker都会产生一个node。
Name：broker名称
File descriptors：broker打开的文件描述符和限制。
Socket descriptors：broker管理的网络套接字数量和限制。当限制被耗尽时，RabbitMQ将停止接受新的网络连接。
Erlang processes：erlang启动的进程数。
Memory：当前broker占用的内存。
Disk space：当前broker占用的硬盘。
Uptime：当前broker持续运行的时长。
Info：节点特征信息。
Reset stats：重启状态。

二、Connections

当前所有客户端活动的连接。包括生成者和消费者。

Virtual host：所属的虚拟主机。
Name：名称。
User name：使用的用户名。
State：当前的状态，running：运行中；idle：空闲。
SSL/TLS：是否使用ssl进行连接。
Protocol：使用的协议。
Channels：创建的channel的总数。
From client：每秒发出的数据包。
To client：每秒收到的数据包。

三、Channels

当前连接所有创建的通道。

channel：名称。
Virtual host：所属的虚拟主机。
User name：使用的用户名。
Mode：渠道保证模式。可以是以下之一，或者不是：C: confirm。T：transactional(事务)。
State ：当前的状态，running：运行中；idle：空闲。
Unconfirmed：待confirm的消息总数。
Prefetch：设置的prefetch的个数。
Unacker：待ack的消息总数。
publish：producter pub消息的速率。
confirm：producter confirm消息的速率。
deliver/get：consumer 获取消息的速率。
ack：consumer ack消息的速率。

四、Exchanges

交换机

Virtual host：所属的虚拟主机。
Name：名称。
Type：exchange type
Features：功能。可以是以下之一，或者不是：D: 持久化。T：Internal，存在改功能表示这个exchange不可以被client用来推送消息，仅用来进行exchange和exchange之间的绑定，否则可以推送消息也可以绑定。
Message rate in：消息进入的速率。
Message rate out：消息出去的速率。

4.1. 页面添加exchange 交换机

virtual host :选择虚拟机
Name ：交换机名子
Type ：交换机类型选择，默认direct 直连模式，fanout 路由模式吗，topic模式
Durability ：是否需要持久化，true为持久化
Auto Delete ：当最后一个绑定到Exchange上的队列删除后，自动删除该Exchange
Internal ：当前Exchange是否用于RabbitMQ内部使用，默认为False
Arguments ：扩展参数，用于扩展AMQP协议，定制化使用

4.2. 交换机类型

Direct exchange(amq.direct): 直连交换机
Fanout exchange(amq.fanout): 扇形交换机(广播)
Headers exchange(amq.match): 头交换机
Topic exchange(amq.topic): 主题交换机

在 RabbitMQ 的管理后台中，Publish message 和 Get Message 是两个用于调试和手动干预的核心功能。它们的操作方式和潜在风险截然不同，理解其背后的机制至关重要。

4.3. 📤 发布消息 (Publish message)

这个功能允许您模拟生产者，向指定的交换机发送一条消息。消息会根据交换机的类型和路由规则，被路由到一个或多个绑定的队列中。

操作步骤：

登录 RabbitMQ 管理后台。
点击顶部菜单栏的 Exchanges。
在交换机列表中，点击您想要发送消息的目标交换机名称（例如 amq.direct, amq.fanout 或自定义的交换机 ex.test.fanout）。
在交换机详情页面，找到 Publish message 区域。
填写关键参数：

Routing key：这是消息的路由键。交换机将根据这个键和自身的类型（如 Direct, Topic）来决定将消息投递给哪个队列。必须与您创建绑定时设置的 Routing key 一致。交换机类型为 Fanout 的情况下，路由键为空。
Payload：在此输入框中填写消息的正文内容（例如：{"event": "test"} {"msg":"MQ扇形测试！7L_PN6Q3exM-qEL3KSX0u"}）。
Headers (可选)：可以设置消息的头部信息，例如 contentType 为 application/json。

点击 Publish message 按钮。

注意事项：

交换机不存储消息：消息是发送到交换机，而不是直接发送到队列。如果交换机没有绑定任何队列，或者没有队列匹配路由规则，消息将会丢失。
消息持久性：通过此方式发布的消息默认是非持久化的（Delivery mode: 1）。这意味着如果 RabbitMQ 服务重启，这些消息将会丢失。
路由是关键：确保您已经创建了目标队列，并且该队列已经通过正确的 Routing key 绑定到了当前交换机。

4.4. 🔍 获取消息 (Get Message)

这个功能允许您从队列中手动拉取并查看消息内容。这是一个高风险操作，需要极其谨慎。

操作步骤：

点击顶部菜单栏的 Queues。
在队列列表中，点击您想要查看消息的队列名称。
在队列详情页面，找到 Get messages 区域。
设置 Ack mode（确认模式），这是最关键的一步。
在 Messages 输入框中填写你想要获取的消息数量。
点击 Get Message(s) 按钮。

⚠️ 关键注意事项：Ack mode 的选择

Ack mode 的选择直接决定了消息被获取后的命运，也是您提到的“消息被删除”问题的根源。

表格

确认模式 (Ack mode)	行为描述	结果与风险
Automatic ack	消息一旦被获取，RabbitMQ 就立即认为它已被成功消费。	消息会从队列中永久删除。这是最危险的模式，因为消息没有经过您的应用程序处理就消失了。
Nack message requeue true (推荐)	获取消息但不发送确认，并立即将消息重新放回队列。	消息不会被删除，会保留在队列中等待正常的消费者处理。这是用于安全查看消息内容的推荐模式。
Reject requeue false	拒绝获取消息，并且不将其重新放回队列。	消息会从队列中永久删除。用于丢弃不需要的消息。

总结与建议：

Get Message 是破坏性操作：管理后台会明确提示 “getting messages from a queue is a destructive action”（从队列获取消息是一个破坏性操作）。
生产环境慎用：在生产环境中，应尽量避免使用 Get Message 功能，尤其是 Automatic ack 模式，因为它会直接导致消息丢失，您的应用程序将无法再消费到这些消息。
安全查看消息：如果只是想查看消息内容以进行问题排查，务必选择 Nack message requeue true 模式。这样既能看到消息，又不会影响应用程序的正常消费流程。

五、Queues

队列

Virtual host：所属的虚拟主机。
Name：名称。
Features：功能。可以是以下之一，或者不是：D: 持久化。
State：当前的状态，running：运行中；idle：空闲。
Ready：待消费的消息总数。
Unacked：待应答的消息总数。
Total：总数 Ready+Unacked。
incoming：消息进入的速率。
deliver/get：消息获取的速率。
ack：消息应答的速率。

5.1. 创建队列queue

type：此queue的类型，默认为classic 主队列，也可以设置为quorum 从队列\
name：此queue的名称
durability：queue中的消息是否要持久化到硬盘
auto delete：如果此queue没有绑定到任何一个exchange，是否自动删除此queue
arguments：设置一些其它参数

六、Admin

管理

在这里插入图片描述

6.1. 用户

Name：名称。
Can access virtual hosts：允许进入的vhost。
Has password：设置了密码。
Tags：角色标签，只能选取一个。
- administrator (超级管理员)：可登陆管理控制台(启用management plugin的情况下)，可查看所有的信息，并且可以对用户，策略(policy)进行操作。
- monitoring(监控者)：可登陆管理控制台(启用management plugin的情况下)，同时可以查看rabbitmq节点的相关信息(进程数，内存使用情况，磁盘使用情况等)
- policymaker(策略制定者)：可登陆管理控制台(启用management plugin的情况下), 同时可以对policy进行管理。
- management(普通管理者)：仅可登陆管理控制台(启用management plugin的情况下)，无法看到节点信息，也无法对策略进行管理。
- none(其他)：无法登陆管理控制台，通常就是普通的生产者和消费者。