我们在我的工作场所有一个围绕RabbitMQ的包装库，由不再在这里工作的人创建。我正在使用Rabbit设计一个新系统，并且正在制定用于声明队列，交换和绑定的最佳方法。我们的Rabbit架构有一些联邦全局区域，每个区域都有多个Rabbit节点。
发布消息和订阅队列的包装器代码每次都重新声明相关的交换，队列和绑定。我担心的是，这可能会在每个消息发布中引入显着的延迟，特别是如果它需要等待确认远程全局区域中存在队列/交换。我希望每秒发布数百万条消息的基准不会为每次发布重新声明交换。
简而言之，这种做法对我来说似乎有点浪费和偏执，但也许我错过了一些东西。
所以我有几个问题：
答案 0 :(得分：15)
重新声明队列并交换显着的性能
它可以用于非常大量的消息
重新声明每次使用一个好的方法，因为它处理由于代理重启或显式删除而导致的队列/交换消失？
＆＃34;好方法＆＃34; - 不。
＆＃34;有效＆＃34;防止消失的交换/队列/绑定导致问题，是的......但在大多数情况下，它不是一件好事，
（如果您只是非常不经常发送消息，可能会出现问题，但是有一个真正令人担心的问题是拓扑被擦干净了）
我们应该只为每个进程声明一次队列和交换并期望它们能够持续整个生命周期吗？
这是我的一般方法。
它打开了拓扑被破坏的可能性，你不知道它。这取决于你是否认为这会真的发生。
是否应在Rabbit配置中声明持久交换和队列，而不是由应用程序声明？
预定义拓扑没有任何问题，但它错过了rabbitmq和amqp协议的大量功能和灵活性。
许多邮件系统需要预定义的拓扑和专用工具来管理拓扑。 amqp完全不同，它允许您根据需要定义拓扑。
如果您处理静态拓扑，那么这可能是一个很好的选择
如果应用程序可能继续使用旧配置声明它们，应如何处理队列/交换的配置更改？应用程序是否应该只处理声明失败并继续发布/使用？
我会使应用程序崩溃并通过您正在使用的任何错误报告机制进行报告。
拓扑变化通常是重要的，并且由于某种原因而完成。如果交换或队列声明需要更改，则可能有充分的理由，并且代码不应继续使用旧的声明。