我有一个 RabbitMQ 的特定用例，我想澄清某些事情并寻求建议。
考虑这种情况：
1- 我发布两条消息，即要执行的任务：messageA，然后是 messageB
2-我的消费者得到了messageA，执行了这个消息中包含的任务，但是在任务运行的时候，服务器崩溃了
我的问题是：当服务器重启时，messageA会重新入队，会在messageB之前重新入队吗（与crash前的顺序相同）？
据我了解，如果服务器崩溃，messageA 将会丢失，因为我的消费者在收到消息时默认已确认。
所以我的想法是分别消费和确认消息：先消费，运行任务，等任务执行成功后再确认消息。
您认为这种方法有问题吗？你会建议我做其他事情吗？
【问题讨论】：
标签： javascript node.js rabbitmq amqp
RabbitMQ 不保持消息的顺序重新排队：
在大多数情况下，是的。假设发布者发布消息 M1、M2、M3 和 M4（按此顺序）在同一通道上并具有相同的路由 信息。如果这些消息被路由到队列，那么它们将 最终以它们发布的相同顺序结束。消费在 队列将产生 M1、M2、M3 和 M4。
但是，只有在没有重新排队的情况下才能保证订单。一种 如果消费者关闭通道，消息将被隐式重新排队 在确认消息之前。例如，如果消费者收到 M1， 无法确认并关闭通道，然后下一个消费者将 按 M2、M3、M4、M1 的顺序接收消息。消息也可以 如果消费者调用 basic.recover{requeue=true}，则显式重新排队。 至少一次交付的常见问题解答在更多内容中谈到了这一点 详细。
这可以做到，但 RabbitMQ 不会自动做到这一点，您需要通过将子消息包装在父消息中来自己管理生命周期。然后，您将拥有管理父消息并在消息 1 成功但消息 2 失败时处理回滚的代码。希望这会有所帮助..
最好的问候
【讨论】：
在 no-ack 模式下使用的消息（请参阅http://www.rabbitmq.com/amqp-0-9-1-reference.html#domain.no-ack）在服务器崩溃后不会重新排队，因为服务器在传递这些消息时完全忘记了这些消息。消费者在传递后对此类消息负责。
仅在成功完成任务后确认消息是您场景中的正确方法。如果您希望消息在代理崩溃后仍然存在，那么您还必须确保队列是持久的，并且消息是持久发布的（传递模式 2），并且发布者确认或事务用于确保将消息写入磁盘.
如果在处理 messageA 时代理崩溃，则将保留消息顺序。如果消费者而不是代理崩溃，那么消息顺序将被颠倒。
【讨论】：