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