rabbitmq - 何时使用 RabbitMQ 声明/绑定(bind)队列和交换

Question

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

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

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

所以我有几个问题:

考虑到全局联盟，重新声明队列和交换是否会对性能造成重大影响？

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

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

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

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

Answer 1

Is re-declaring the queues and exchanges a significant performance hit

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

Is re-declaring on each use a good approach because it handles queues/exchanges disappearing due to broker restarts or explicit deletion?

“好方法” - 不。

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

(如果您不经常发送消息，也许可以，确实有理由担心拓扑被清除干净)

Should we just declare queues and exchanges once per process and expect them to last the whole lifetime?

这是我的一般做法。

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

Should durable exchanges and queues be declared in Rabbit config and not declared by the applications at all?

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

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

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

How should config changes for queues/exchanges be handled if applications may continue to declare them with old config? Should applications just handle the declare failure and continue to publish/consume?

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

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