Nack是 AMQP 协议的 RabbitMQ 特定增强。它允许消息的使用者在消息未成功处理时通知服务器。我想你已经到了这一步。
这里有趣的是，AMQP 最初并不认为Nack是必要的。为什么？因为消费者无法处理消息时的 AMQP 行为是消费者在不ack-ing 消息的情况下关闭连接。在这种情况下，消息会自动按照原来的顺序重新排队，并通过redelivered设置标志传递给下一个可用的使用者。
为什么会这样？
因为 aNack表示消费者的问题，而不是消息。如果消息本身是坏消息，AMQP 假设消费者足够聪明，可以识别出这个ack消息，然后采取程序员设计的任何其他步骤来处理坏消息。
RabbitMQ 添加了Nack带requeue参数的函数。默认情况下，requeue为 true - 意味着在 nack 时，代理将重新排队消息。这符合 AMQP 设计的初衷。但是，如果您传递requeue为 false，则代理将死信消息。这是通常由使用 AMQP 的智能应用程序架构师设计的行为的捷径，因此您可以将其视为对程序员的便利。
两者之间的区别
在第一种情况下，Nack指示消息使用者存在问题。消费者在解决问题时应该让自己离线。在第二种情况下，Nack表示消息有问题。第一种情况是暂时性问题，而第二种情况是永久性故障。
如果我不能处理特定的消息是什么，现在可能过几天吧？
如果您的消息传递结构设计得当，这将永远不会发生。如果一个特定的消息需要与另一条消息不同的处理路径或资源，则该消息类型应该有自己的队列。当处理这些消息的依赖项离线或不可用时，该队列的使用者可以停止消费。