在 RabbitMQ 中需要单独的死信交换吗？

Posted 2023-02-16

【中文标题】在 RabbitMQ 中需要单独的死信交换吗？

【英文标题】：Separate dead letter exchange necessary in RabbitMQ?

【发布时间】：2021-01-18 20:23:25

【问题描述】：

我已经为我的队列设置了死信路由，以延迟几秒钟将被拒绝的消息重新排队，从而防止临时的消费者错误阻塞队列。我已经设置好了，所以工作队列和死信队列都绑定到同一个交换：

外部产生的传入消息被路由到交换器，交换器将它们放置在工作队列中。在处理消息期间，消费者可能会由于一些临时错误而失败（想想爬虫从网站收到错误 500）。 而不是拒绝消息并拥有它 再次放置在队列的头部（导致无限循环），我们将被拒绝的消息（带有requeue=0）路由到交换器，添加死信队列作为路由键。在这里，每条消息都会收到 X 秒的 TTL，在此之后它将被拒绝，因此会使用路由密钥 se 路由回 Exchange 到原始工作队列。

但是，看网上的文献和例子，似乎每个人都建议路由到单独的死信交换：

外部产生的传入消息被路由到工作交换，然后将它们放入工作队列中。如果消费者失败，消息将被拒绝（requeue=0）并将被路由到死信交换。死信交换将消息路由到死信队列，在那里消息的 TTL 将过期，再次被拒绝的消息将被路由回工作交换。

---

与第一个设计相比，第二个设计有什么关键优势吗？我无法识别任何东西，但我对 RabbitMQ 并不太自信。

【参考方案1】：

这取决于您使用的交换类型，以及您需要执行的其他路由。如果您对原始消息和重新排队的消息使用相同的交换，则需要区分：

新消息，可能被路由到多个队列，或者根本不路由 失败的消息，应该只路由到延迟队列 延迟消息，应仅路由到失败的单个队列

在my implementation of this pattern 中，我使用了两个 额外的交换（均按需动态声明），以便它尽可能独立于原始路由配置：

原始消息由消费者确认，并手动重新发布到“开始”交换。这提供了一些额外的灵活性，例如在消息上设置自定义标头，以及将具有不同 TTL 的多个延迟队列附加到同一工作队列。 “开始”交换是一个扇出交换，绑定到特定的“等待”队列，如第二张图所示。 当“等待”队列中的消息 TTL 到期时，它会被路由到单独的“完成”交换，设置为死信交换。 该交换也是一个扇出交换，仅绑定到原始工作队列。这可确保不会为第一次成功处理它的其他队列创建额外的消息副本。 因此，消息将返回原始队列，并带有其原始路由键。