1. 概述
在使用 RabbitMQ 消息队列时，监控队列状态和消息流动情况对于理解系统行为至关重要。
本文将介绍如何使用 RabbitMQ 的管理控制台来监控队列统计信息。此外，我们还会探讨 自动确认模式（autoAck） 和 预取机制（prefetch） 是如何导致我们看到的待处理消息数与实际情况不符的。
2. RabbitMQ 环境搭建
我们先从搭建 RabbitMQ 环境开始，以便演示各种监控工具。可以使用 docker run 命令快速启动一个带有管理插件的 RabbitMQ 容器：
$ docker run -d --name rabbitmq \
-p 5672:5672 \
-p 15672:15672 \
rabbitmq:3.13.7-management
91002cd436168bcee734f784f80c28ec09ee480635be88167264089af947cf4c
该命令使用 rabbitmq:3.13.7-management 镜像创建并启动了一个 RabbitMQ 容器。镜像名中的 management 表示我们启用了管理控制台功能。
2.1 创建队列
接下来，我们使用 rabbitmqadmin 工具在容器内创建一个队列：
$ docker exec rabbitmq rabbitmqadmin declare queue name=test_queue
queue declared
该命令创建了一个名为 test_queue 的队列。
2.2 发布消息
为了后续演示更直观，我们向队列中发布一些测试消息：
$ for i in {1..5}; do
docker exec rabbitmq rabbitmqadmin publish \
exchange=amq.default \
routing_key=test_queue \
payload="test message $i"
done
Message published
Message published
Message published
Message published
Message published
我们使用 for 循环执行了五次 rabbitmqadmin publish 命令，向 test_queue 中发送了五条消息。
3. RabbitMQ 管理控制台
RabbitMQ 管理控制台是一个图形化界面（GUI）工具，用于监控和管理 RabbitMQ 实例。它提供了丰富的队列信息，包括消费者数量、消息发布和消费速率、以及队列状态等。
要访问管理控制台，只需访问 http://localhost:15672。默认用户名和密码均为 guest。
3.1 概览页面（Overview）
登录后，首先进入的是概览页面：
该页面主要包括两个图表：
- Queued messages：显示当前所有队列中消息的总数，包括已准备好投递的消息和已投递但尚未确认的消息。
- Message rates：显示消息的发布速率，单位为每秒消息数。
下方还展示了当前连接数、通道数、交换机、队列和消费者的数量。
这些信息提供了 RabbitMQ 实例的整体运行状况，但若要深入分析某个队列的状态，需要进入“队列”页面。
3.2 队列与流（Queues and Streams）
进入“Queues and Streams”页面，可以看到所有队列的详细信息：
每行展示了三个主要信息组：
- 队列基本信息：名称、类型、状态。
- 消息数量：包括 ready（待处理）、unack（未确认）等状态的消息数量。
- 消息速率：入队、出队和确认的速率。
通过这些数据，我们可以判断消费者是否能及时处理消息。例如，如果入队速率持续高于出队速率，说明消费者处理能力不足，可能需要扩容。
4. 为什么待处理消息数可能不准？
在监控 RabbitMQ 队列时，有时会发现监控工具显示的消息数与实际预期不一致。这通常是由以下两个机制引起的：
4.1 预取机制（Prefetch）
预取机制决定了消费者在一次请求中可以从 RabbitMQ 获取多少条消息。这个机制可以减少网络请求次数，提高消费效率。
例如，若预取数量设为 50，消费者只需一次请求就能获取最多 50 条消息，而不是发起 50 次请求。
4.2 消息确认模式（Acknowledgement Mode）
RabbitMQ 支持两种确认模式：
- 自动确认（autoAck）：消息一旦发送给消费者，就被认为已成功投递。即使消费者后续崩溃，消息也不会被重新投递。
- 手动确认（manualAck）：消费者必须显式发送 ACK，消息才会被标记为已处理。否则，消息会被重新入队。
4.3 预取 + 自动确认的组合问题
当消费者使用 自动确认 模式且设置了较大的预取数量时，监控工具显示的待处理消息数可能与实际不符。
举个例子：
- 我们向
test_queue发送了 5 条消息。 - 队列监控显示有 5 条 ready 状态的消息。
- 启动一个单线程消费者，设置 prefetch=10，autoAck=true。
- 消费者一次性获取了所有 5 条消息。
- 由于是 autoAck 模式，RabbitMQ 认为这 5 条消息已被成功消费，监控显示 ready 和 unack 消息数都变为 0。
- 但实际上，消息可能还在消费者的本地缓冲中，尚未处理。
⚠️ 这就是为什么在某些情况下，监控工具显示的“待处理”消息数为 0，但消费者还在处理消息的原因。
5. 总结
本文介绍了 RabbitMQ 的管理控制台如何帮助我们监控队列状态，并强调了两个容易导致监控数据“误导”的机制：
✅ 预取机制 提高了消费效率，但也可能导致监控工具显示的消息数偏低。
✅ 自动确认模式 在某些场景下可能导致消息被提前标记为“已消费”。
因此，在实际使用中，建议根据业务需求选择合适的预取数量和确认模式。如果对消息可靠性要求较高，建议使用手动确认（manualAck）并适当控制预取数量，以避免监控数据失真。