RabbitMQ主题交流:1个交流与许多交流 [英] RabbitMQ Topic exchanges: 1 Exchange vs Many Exchanges

问题描述

在我的场景中，我需要执行一系列流程，每个步骤都已完成并在独立的应用程序中扩展.我正在将主题交流用于所有交流.当前的拓扑是这样的:

I have a scenario where I have a series of processes I need to perform, each step is done and scaled in independent applications. I am using topic exchanges for all exchanges. Current topology is something like this:

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

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

我们正在版本化"队列，以处理可能影响消息结构的需求变更.绑定可能看起来像这样:

We are "versioning" our queues to deal with probable requirements changes effecting message structure. Bindings might look something like this:

step1.exchange通过绑定键step1.v1绑定到step1.v1.queue

step1.exchange bound to step1.v1.queue with binding key step1.v1

step1.exchange使用绑定​​键step1.v2绑定到step1.v2.queue

step1.exchange bound to step1.v2.queue with binding key step1.v2

还有其他与版本无关的绑定模式，这些绑定模式也使主题交换成为适当的选择.但是，我们只用一次交换就可以完成同一件事.

There are other binding patterns that are not version related that also make topical exchanges the appropriate choice. However we could get away with only using one exchange to accomplish the same thing.

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

推荐答案

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

I simply copy some key fragments for you.
https://spring.io/blog/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/

• 如果应用程序图中的路由键域有限，那么许多扇出交换可能是正确的选择(每个路由键1:1交换映射)

• If you have a finite domain of routing keys in an application’s graph then many fanout exchanges might be the right fit (1:1 mapping of exchange per routing key)

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

If you have a potentially infinite number of routing keys, consider topic exchanges

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

For topic routing, performance decreases as the number of bindings increase

Fanout交换非常快，因为如果绑定到大量变化的队列中，它们尚无路由要处理

Fanout exchanges are very fast because they have no routing to process yet if bound to a large number of queues that changes

直接交换是主题交换的一种较快形式，只要您不需要通配符

Direct exchanges are a faster form of topic exchanges, provided you do not need the wild card

与具有更多绑定，更少交换和队列的拓扑相比，在100,000多个队列中进行故障排除可能很乏味

Troubleshooting problems across 100,000+ queues could be tedious versus a topology with more bindings, fewer exchanges and queues

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

A very high number of exchanges and queues take up more memory which may be significant but this really depends

自2011年3月23日发布的RabbitMQ 2.4.0起，新的主题路由算法优化已可用，其峰值速度比以前的主题算法快60倍.因此，一个建议是减少交换和队列，并增加路由，因为现在的时间增加很小.

As of RabbitMQ 2.4.0, released March 23, 2011, a new topic routing algorithm optimization is available that is 60 times faster at peak than the previous topic algorithm. Due to this, one recommendation is to go for less exchanges and queues, and more routing because the time increase is now minimal

这篇关于RabbitMQ主题交流:1个交流与许多交流的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！