Architecture RabbitMQ中是否需要单独的死信交换？

我已经在队列中设置了死信路由，以延迟几秒钟重新获取被拒绝的消息，防止临时使用者错误阻塞队列。我已将其设置为使工作队列和死信队列都绑定到同一个交换机：

外部生成的传入消息被路由到exchange，exchange将它们放入工作队列中。在处理消息期间，消费者可能会由于一些临时错误而失败（假设爬虫程序从网站接收到错误500）。
而不是拒绝信息并拥有它 我们将被拒绝的消息（使用

requeue=0

）再次放在队列的最前面（导致无限循环），并将死信队列添加为路由密钥。在这里，每条消息都会收到一个X秒的TTL，在该TTL之后，它将被拒绝，并因此使用路由密钥se将其路由回原始工作队列的exchange

然而，从网上的文献和例子来看，每个人似乎都建议使用单独的死信交换：

外部生成的传入消息被路由到工作交换，工作交换将它们放置在工作队列中。如果消费者失败，消息将被拒绝（使用

requeue=0

），并将被路由到死信交换机。死信交换将消息路由到死信队列，在那里消息TTL将过期，再次被拒绝的消息将路由回工作交换

---

---

与第一种设计相比，第二种设计是否有一些关键优势？我无法识别任何，但我对RabbitMQ也不是很有信心。

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

• 新消息，可能路由到多个队列，或者根本没有
• 失败的消息，应仅路由到延迟队列
• 延迟消息，应仅路由到失败的单个队列

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

• 原始消息由使用者确认，并手动重新发布到“开始”交换。这允许一些额外的灵活性，例如在消息上设置自定义头，并将具有不同TTL的多个延迟队列连接到同一工作队列
• “begin”交换是扇出交换，绑定到特定的“waiting”队列，如第二个图所示
• 当消息TTL在“等待”队列中过期时，它被路由到单独的“完成”交换，设置为死信交换
• 该交换也是扇出交换，只绑定到原始工作队列。这可确保不会向第一次成功处理消息的其他队列创建消息的额外副本
• 因此，消息返回到原始队列中，并带有其原始路由密钥