22

我有一个场景，我需要执行一系列流程，每个步骤都在独立的应用程序中完成和扩展。我正在为所有交流使用主题交流。当前的拓扑是这样的：

P -> X -> Q -> C/P -> X -> Q -> C

我们正在“版本化”我们的队列以处理影响消息结构的可能需求更改。绑定可能看起来像这样：

step1.exchange 绑定到 step1.v1.queue 与绑定键 step1.v1

step1.exchange 绑定到 step1.v2.queue 与绑定键 step1.v2

还有其他与版本无关的绑定模式也使局部交换成为适当的选择。但是，我们可以只使用一次交换来完成同样的事情。

TLDR：当您的用例可以以任何一种方式工作时，使用多个主题交换而不是一个主题交换是否有好处？

4

2 回答 2

14

我只是为您复制一些关键片段。
https://spring.io/blog/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/

  • 如果您在应用程序的图中有一个有限的路由键域，那么许多扇出交换可能是合适的（每个路由键交换的 1:1 映射）

  • 如果您有可能无限数量的路由键，请考虑主题交换

  • 对于主题路由，性能随着绑定数量的增加而降低

  • 扇出交换非常快，因为如果绑定到大量更改的队列，它们还没有要处理的路由

  • 直接交换是一种更快的主题交换形式，前提是您不需要通配符

  • 与具有更多绑定、更少交换和队列的拓扑相比，对超过 100,000 个队列的问题进行故障排除可能会很乏味

  • 大量的交换和队列占用了更多的内存，这可能很重要，但这真的取决于

从 2011 年 3 月 23 日发布的 RabbitMQ 2.4.0 开始，提供了一种新的主​​题路由算法优化，其峰值速度比以前的主题算法快 60 倍。因此，一个建议是减少交换和队列，增加路由，因为时间增加现在很小

于 2017-07-13T02:22:08.193 回答
6

看看“使用 RabbitMQ 实现性能和可扩展性的路由拓扑” http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/

于 2012-07-23T10:14:13.410 回答