我的经验：在发布/订阅的情况下，如果用户的NACK消息，该消息NACKED立即在队列前重新排队，这将是下一个消息的订户得到。
是否有办法避免这种情况？是否可以NACK的方式一条消息，下一条消息肯定不会是一个公正的裸体？
我如何使用Node.js和amqp.node与RabbitMQ的沟通
Nack是特定的RabbitMQ增强到AMQP协议。它允许消息的消费者在未成功处理的消息通知服务器。我想你了这么远了。
这里有趣的是，AMQP最初没有考虑Nack是必要的。为什么？因为当消费者是无法处理的消息AMQP的行为是对消费者关闭而没有连接ack-ING的消息。在这种情况下，该邮件会自动在它原来的顺序重新排队，并传递到与redelivered标志设置下一个可用的消费者。
为什么会这样？
因为Nack表示与消费者，而不是信息的问题。如果消息本身是坏的，AMQP假定消费者就足以认识到这一点聪明，ack信息，然后采取任何其他步骤的程序员专门用来对付坏消息。
的RabbitMQ加入Nack函数，它接受一个requeue参数。默认情况下，requeue是真实的 - 于NACK的意思，代理将重新排队的消息。这是与AMQP的设计初衷是一致的。但是，如果你通过requeue虚假，代理将死信消息。这是一个快捷方式通常会已通过使用AMQP智能应用建筑师设计的行为，所以你可以认为这是为了方便程序员。
差的两
在第一种情况下，Nack indcates与消息消费者的问题。消费者应采取自身下线，而它的作品了它的问题。在第二种情况下，Nack指示与该消息的问题。第一种情况是一过性的问题，而第二个是永久性故障。
如果我不能，但现在也许以后处理特定的消息是什么？
如果您的邮件结构设计得当，这将永远是正确的。如果一个特定的消息需要比另一消息不同的处理路径或资源，该消息类型应该有它自己的队列。该队列的消费者可以停止食用时用于处理这些消息的依赖脱机或不可用。
问：我的经验：在发布/订阅的情况下，如果用户的NACK消息，该消息NACKED立即在队列前重新排队，这将是下一个消息的订户得到。
对，那是正确的。当一个消息被以channel.basicNack重新排队，则如果可能的话被放置到其初始位置在其队列中。如果没有（由于并发的交付和当多个消费者共享队列从其他消费者确认），该消息将被重新排队到一个位置更靠近队列头。来源：https://www.rabbitmq.com/nack.html
问：是否有办法避免这种情况？是否可以NACK的方式一条消息，下一条消息肯定不会是一个公正的裸体？
这是不可能的NACK来实现这一目标。实现这一目标的方法之一是重新发布的消息回到队列在以往任何时候NACK需要。
作为一般规则，你可以考虑，如果你的消费者正常运行，你应该总是ACK消息，处理该邮件（包括错误或成功）无论结果如何。
你可以拒绝/ NACK与重新排队坏的格式化的消息= false将其路由到一纸空文交流并在其上有行动（绑定队列和consume如验尸分析），或选择确认，并采取一切必要措施（如发送其他的消息一样错误请求消息，...）。
到（几乎）从来没有问题的最好办法是ACK作为处理消息的最后一个动作，并准备好处理重复传递（幂等可以帮助）。您可以在交货时立即确认，但如果消费者崩溃，邮件丢失（您可能需要自己处理这种情况 - 有这许多的模式）。
希望这可以帮助。