最可靠方式是调用 RabbitMQ Management Plugin 的 /api/queues/{vhost}/{name} 接口获取 messages_published_details.rate 和 messages_consumed_details.rate 字段，它们是 Broker 基于 5 秒滑动窗口计算的瞬时速率；使用 rabbitmq-http-client 时必须传 true 启用 include_stats，否则 publishDetails/consumeDetails 为 null；需 URL 编码 vhost、确保 monitoring 权限、判空 rate 值，并建议 10 秒轮询一次。
用 RabbitMQ HTTP API 拿队列级速率指标最可靠
官方 Java 监控库（rabbitmq-http-client）本身不直接暴露“发布速率”“消费速率”这类聚合指标，它只封装了 HTTP API 的调用。真正能拿到实时速率的，是 RabbitMQ 自带的 Management Plugin 提供的 /api/queues/{vhost}/{name} 接口——它返回的 messages_published_details.rate 和 messages_consumed_details.rate 字段就是你要的每秒发布/消费条数。
注意：这些 rate 字段是服务端基于最近 5 秒滑动窗口计算的瞬时速率，不是累计值，也不依赖客户端采样，所以比自己计数更准、更轻量。
- 必须启用 Management Plugin：
rabbitmq-plugins enable rabbitmq_management - vhost 名要 URL 编码（比如
/要写成%2F），否则 404 - 账号需有
monitoring权限（至少要有read权限访问/api/queues）
rabbitmq-http-client 怎么正确构造请求拿 rate 字段
别直接 new Client 然后调 getQueue——那个方法返回的是 QueueInfo 对象，而它的 publishDetails 和 consumeDetails 字段默认为 null，因为 client 默认不拉取 stats 数据。
必须显式开启 stats 参数：
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
RabbitMQHttpClient client = new RabbitMQHttpClient("http://localhost:15672", "guest", "guest");
QueueInfo queue = client.getQueue("%2F", "my_queue", true); // 第三个参数 true 表示 include_stats = true
Double publishRate = queue.getMessagesPublishedDetails().getRate();
Double consumeRate = queue.getMessagesConsumedDetails().getRate();
- 如果传
false或省略该参数，getMessagesPublishedDetails()返回null，NPE 风险很高 - rate 值可能为
null（比如队列刚创建还没流量），务必判空 - client 默认超时是 30 秒，高频轮询建议设短点：
client.setReadTimeout(3_000)
为什么不用 queue.declare 或 AMQP 协议本身获取速率
AMQP 协议层（包括 Channel、Connection）完全不提供速率统计能力。你调 channel.queueDeclare 只能得到声明结果，和当前吞吐毫无关系。有人试图用 channel.addReturnListener 或 channel.addShutdownListener 拦截消息来自己计数，这既不准（漏发、重试、confirm 失败都难覆盖），又加重客户端负担，还无法反映 broker 真实负载。
- Management API 的 rate 是 broker 内核直接上报的，含 confirmed/published/consumed 全链路数据
- 自己计数无法区分“发出去但没 confirm”的消息，会高估发布成功率
- HTTP API 支持批量查多个队列（
/api/queues不带 name），适合做统一监控面板
轮询间隔设多少才合理？别太勤也别太懒
rate 字段是 5 秒滑动窗口，意味着两次请求间隔小于 5 秒，数据大概率重复；大于 15 秒，就可能错过短时毛刺。生产环境建议 10 秒轮询一次。
- 低于 5 秒：HTTP 开销翻倍，且 rate 值基本不变，纯属浪费
- 高于 30 秒：突发流量（如 8 秒脉冲）可能被平滑掉，告警延迟大
- 如果用 Spring Boot，可用
@Scheduled(fixedDelay = 10000)控制节奏，别用 cron
rate 字段的精度取决于 broker 统计周期，不是客户端能改的——这点容易被忽略，很多人以为调小轮询间隔就能“看到更细粒度”，其实只是反复读同一组数字。
