RabbitMQ死信处理保证

如果使用publisher confirms，我可以（合理地）确保发送到RabbitMQ服务器上的exchange的消息以及从RabbitMQ服务器接收到的ACK不会丢失，即使RabbitMQ服务器崩溃（例如断电）

但是，当消费者手动拒绝消息后，消息到达死信交换时会发生什么情况？（channel.basicrject，我使用Spring AMQP。）

我是否仍然可以确定，在原始消息从使用者正在侦听的队列中退出队列，并且RabbitMQ服务器随后崩溃的情况下，在RabbitMQ服务器重新启动后，我最终会在绑定到死信交换的队列中找到该消息（如果正常情况下，信息会到达那里）

---

如果答案是否定的，有没有办法确保情况属实？

正如@GaryRussell所建议的，我在

rabbitmq用户

Google group上发布了一个类似的问题

这是我从丹尼尔·费多托夫那里得到的答案

"Hi,

There is no delivery guarantees in place. Dead lettering does not check if the message was enqueued or saved to disk.
Dead-lettering does not use publisher confirms or any other confirm mechanisms.

It's not that easy to implement reliable dead-lettering from one queue to another and there are plans to address this issue eventually, but it may take a while.

If you want to safely reject messages from the consumer without a risk of losing them - you can publish them from the consumer application manually to the dead-letter queue, wait for the confirmation and then reject."

---

嗨，John，在我的上一个项目中，我们有RabbitMQ，带有拒绝和死信。根据我们的经验，我们从未丢失过消息。我们起诉这些队列以查找消息问题或重新处理。感谢您的评论；但是，由于我知道RabbitMQ是在特别关注并发性的情况下创建的，我想知道ow我所描述的情况是否有保证（从某种意义上说，这种情况已被考虑在内；当然，如果操作系统受到损坏等，则没有保证）。我最好的猜测是，在将它写入DLQ（如果有来自DLX的路由）之前，它不会从主队列中删除，但如果没有从DLX到队列的路由，则将被丢弃。但是，您应该在RabbitMQ工程师常去的

RabbitMQ用户

Google组上询问有关RabbitMQ内部的问题；他们不会监控堆栈溢出。如果您在那里得到答案，我建议您将其添加到此处作为答案。