rabbitmq - 为什么我在重新排队时从 RabbitMQ 收到相同的消息?

标签 rabbitmq amqp

背景

我的队列中有两条消息:

  • 酒吧

我有一个 channel ,一个 Qos 处于事件状态且预取计数为 1 的消费者。

场景

消息传递 foo 传入,我使用 requeue=true 拒绝该消息。

预计: 发送的下一条消息是 bar

实际: 发送的下一条消息是 foo

问题:

为什么我的消费者收到的是刚刚重新排队的消息而不是下一条消息?我怎样才能得到上面描述的结果?

我预计重新排队的消息位于队列的末尾。

我考虑过确认并重新发布该消息,但这会带来丢失消息的风险。

最佳答案

来自https://www.rabbitmq.com/semantics.html

Messages can be returned to the queue using AMQP methods that feature a requeue parameter (basic.recover, basic.reject and basic.nack), or due to > a channel closing while holding unacknowledged messages. Any of these scenarios caused messages to be requeued at the back of the queue for RabbitMQ releases earlier than 2.7.0. From RabbitMQ release 2.7.0, messages are always held in the queue in publication order, even in the presence of requeueing or channel closure.

强调我的

因为您只有一个消费者,所以这种行为是正常的

您可以将消息重新发布到同一队列, 这将确保问题消息最终出现在尾部。

您的另一个选择是为失败的消息创建一个新队列,这样您就可以 分别处理。

关于rabbitmq - 为什么我在重新排队时从 RabbitMQ 收到相同的消息?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/36197347/

相关文章:

rabbitmq - Spring & RabbitMQ - 在运行时注册队列

php - 有没有人在 windows x64 上为 php 5.2.x 编译了一个 rabbitmq/amqp 库

.net - 在NServiceBus中为RabbitMQ交换MSMQ

Spring AMQP RPC 非默认交换

macos - PHP 和 AMQP RabbitMQ 消费者

java - Spring Cloud 流: Republish to other amqp connection if current connection throws exception

python - Celery 中的PeriodicTask run() 方法拥有自己的参数

rabbitmq - RabbitMQ实际上如何物理存储消息?

php - Symfony 信使队列与绑定(bind)键 - 重试策略

Azure IoT 中心 AMQP 通信多路复用