我有一个场景，我需要执行一系列过程，每个步骤都在独立的应用程序中完成并缩放。我正在为所有交易所使用主题交换。当前的拓扑结构如下：
P - ＆gt; X - ＆gt;问 - ＆gt; C / P - ＆gt; X - ＆gt;问 - ＆gt; ç
我们正在“版本化”我们的队列以处理影响消息结构的可能的需求更改。绑定可能看起来像这样：
step1.exchange绑定到带有绑定键step1.v1
的step1.v1.queuestep1.exchange绑定到step1.v2.queue，带有绑定键step1.v2
还有其他与版本无关的绑定模式也使得主题交换成为合适的选择。但是，我们只能使用一个交换来完成同样的事情。
TLDR：当您的用例以任何一种方式运作时，使用多个主题交换而非一个主题交换是否有益？
答案 0 :(得分：8)
使用RabbitMQ查看“使用RabbitMQ实现性能和可伸缩性的拓扑拓扑”http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/
答案 1 :(得分：1)
我只是为你复制一些关键片段 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倍。因此，一个建议是减少交换和队列，以及更多路由，因为时间增加现在是最小的