何时使用 RabbitMQ 声明/绑定队列和交换答案

【问题标题】：When to declare/bind Queues and Exchanges with RabbitMQ何时使用 RabbitMQ 声明/绑定队列和交换
【发布时间】：2016-05-28 11:45:02
【问题描述】：

在我的工作场所，我们有一个围绕 RabbitMQ 的包装库，由不再在这里工作的人创建。我正在使用 Rabbit 设计一个新系统，并且正在制定声明队列、交换和绑定的最佳方法。我们的 Rabbit 架构有几个联合的全局区域，每个区域都有多个 Rabbit 节点。

发布消息和订阅队列的包装代码每次都重新声明相关的交换、队列和绑定。我担心这可能会给每条消息发布带来很大的延迟，特别是如果它需要等待确认远程全局区域中存在队列/交换。我希望每秒数百万条消息的基准不会为每次发布重新声明交换。

简而言之，这种方法对我来说似乎有点浪费和偏执，但也许我错过了一些东西。

所以我有几个问题：

【问题讨论】：

【解决方案1】：

重新声明队列和交换对性能有重大影响

它可以用于非常大量的消息

在每次使用时重新声明是否是一种好方法，因为它可以处理由于代理重启或显式删除而导致的队列/交换消失？

“好方法” - 不。

“有效”防止消失的交换/队列/绑定引起问题，是的……但在大多数情况下，这不是一件好事

（如果您只非常不频繁地发送消息，也许可以，确实有理由担心拓扑被擦除干净）

我们是否应该只为每个进程声明一次队列和交换，并期望它们持续整个生命周期？

这是我的一般方法。

它打开了拓扑被破坏而你不知道的可能性。这取决于你是否认为这真的会发生。

是否应该在 Rabbit 配置中声明持久交换和队列，而不是由应用程序声明？

预定义拓扑没有什么问题，但是它错过了rabbitmq和amqp协议的很多功能和灵活性。

许多消息传递系统需要预定义的拓扑和专门的工具来管理拓扑。 amqp 的不同之处在于它允许您根据需要定义拓扑。

如果您处理静态拓扑，那么这对您来说可能是一个不错的选择

如果应用程序可以继续使用旧配置声明队列/交换的配置更改，应如何处理它们？应用程序是否应该只处理声明失败并继续发布/消费？

我会让应用程序崩溃并通过您使用的任何错误报告机制进行报告。

进行拓扑更改通常很重要，并且是有原因的。如果交换或队列声明需要更改，可能是有充分理由的，代码不应继续使用旧声明。

【讨论】：