何时声明/绑定队列以及与RabbitMQ的交换

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

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

简言之，这种方法对我来说似乎有点浪费和偏执，但也许我遗漏了什么

所以我有几个问题：

• 鉴于全球联盟，重新声明队列和交换是否会对性能造成重大影响
• 每次使用时重新声明是否是一种好方法，因为它可以处理由于代理重新启动或显式删除而消失的队列/交换
• 我们是否应该只为每个进程声明一次队列和交换 希望它们能持续一辈子
• 持久性交换和队列是否应该在Rabbit配置中声明，而不是由应用程序声明
• 如果应用程序可能继续使用旧配置声明队列/交换的配置更改，应如何处理这些更改？应用程序是否应该处理声明失败并继续发布/使用

重新声明队列和交换是否会对性能造成重大影响

它可以用于大量的消息

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

“好方法”-不

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

（如果您只发送很少的消息，可能还可以，但确实有理由担心拓扑会被清除）

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

这是我的一般做法

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

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

预定义的拓扑没有问题，但它忽略了rabbitmq和amqp协议的强大功能和灵活性

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

如果您处理的是静态拓扑，那么这可能是一个很好的选择

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

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

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