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