我的经验:在发布/订阅场景中，如果订阅者 nacks 一条消息，则该 nacks 消息会立即在队列的前面重新排队，这将是订阅者获得的下一条消息。
有没有办法避免这种情况？是否有可能以一种下一条消息绝对不是刚刚收到的消息的方式来接收一条消息？
我正在使用 Node.js 和 amqp.node与 RabbitMQ 通信
最佳答案
Nack是对 AMQP 协议(protocol)的特定于 RabbitMQ 的增强。它允许消息的使用者在收到消息时通知服务器 不是 成功处理。我想你已经走到这一步了。
这里有趣的是，AMQP 最初并没有考虑 Nack是必要的。为什么？因为当消费者无法处理消息时的 AMQP 行为是让消费者在没有 ack 的情况下关闭连接。 - 消息。在这种情况下，消息会自动按照原来的顺序重新排队，并使用 redelivered 传递给下一个可用的消费者。标志设置。
为什么会这样？
因为一个 Nack表示消费者有问题，而不是消息。如果消息本身是错误的，AMQP 假设消费者足够聪明，可以识别这一点，ack消息，然后采取程序员设计的任何其他步骤来处理不良消息。
RabbitMQ 添加了 Nack接受 requeue 的函数范围。默认情况下，requeue是真的 - 意思是在 nack 上，代理将重新排队消息。这符合 AMQP 设计的初衷。但是，如果您通过 requeue如果为 false，代理将死信消息。这是通常由智能应用程序架构师使用 AMQP 设计的行为的捷径，因此您可以将其视为对程序员的一种方便。
两者的区别
在第一种情况下，Nack表明消息消费者有问题。消费者在解决问题时应该让自己离线。在第二种情况下，Nack表示消息有问题。第一种情况是暂时的问题，而第二种情况是永久性故障。
如果我现在不能处理某条特定消息，但以后可能会怎样？
如果您的消息传递结构设计得当，这将永远不会是真的。如果一条特定消息需要与另一条消息不同的处理路径或资源，则该消息类型应该有自己的队列。当处理这些消息的依赖项脱机或不可用时，该队列的消费者可以停止消费。
关于node.js - RabbitMQ NACK 消息，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/54406504/