RabbitMQ - 获取排队的消息总数
我有一个监控 RabbitMQ 队列的 Java 客户端.我可以使用此代码获取当前队列中的消息数
I have a Java client which monitors RabbitMQ queue. I am able to get the count of messages currently in queue with this code
@Resource
RabbitAdmin rabbitAdmin;
..........
DeclareOk declareOk = rabbitAdmin.getRabbitTemplate().execute(new ChannelCallback<DeclareOk>() {
public DeclareOk doInRabbit(Channel channel) throws Exception {
return channel.queueDeclarePassive("test.pending");
}
});
return declareOk.getMessageCount();
我想了解更多详细信息,例如 -
I want to get some more additional details like -
- 当前排队项目的消息正文.
- 自队列创建以来在队列中排队的消息总数.
有没有办法在 Java 客户端中检索这些数据?
Is there any way to retrieve these data in Java client?
推荐答案
使用 AMQP 协议(包括 RabbitMQ 实现)您无法 100% 保证获得此类信息.
With AMQP protocol (including RabbitMQ implementation) you can't get such info with 100% guarantee.
与消息计数最接近的数字是使用 queue.declare-ok
(AMQP.Queue.DeclareOk
在 java AMQP 客户端库中).
The closest number to messages count is messages count returned with queue.declare-ok
(AMQP.Queue.DeclareOk
in java AMQP client library).
虽然您使用 queue.declare-ok
收到的消息计数可能与队列中的确切消息数量匹配,但您不能依赖它,因为它不计算等待确认或发布到队列的消息事务但尚未提交.
Whilst messages count you receive with queue.declare-ok
may match exact messages number enqueues, you can't rely on it as it doesn't count messages which waiting acknowledges or published to queue during transaction but not committed yet.
这真的取决于你需要什么样的精度.
It really depends what kind of precission do you need.
对于排队的消息正文,您可能需要手动提取队列中的所有消息,查看它们的正文并将它们放回队列.这是做你想做的事的唯一方法.
As to enqueued messages body, you may want to manually extract all messages in queue, view their body and put them back to queue. This is the only way to do what you want.
您可以使用 管理插件,RabbitMQ 管理 HTTP API 和 rabbitmqctl 实用程序(参见 list_queues、list_channels).
You can get some information about messages count with Management Plugin, RabbitMQ Management HTTP API and rabbitmqctl util (see list_queues, list_channels).
自创建队列以来,您无法获得已发布消息的总数,而且我认为没有人在它无用的情况下实现此类统计信息(仅供参考,消息流平均每秒 10k,您甚至不会在几千年内达到 uint64).
You can't get total published messages count since queue was created and I think nobody implement such stats while it useless (FYI, with messages flow in average 10k per second you will not even reach uint64 in a few thousand years).
相关文章