Menu
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
We are "versioning" our queues to deal with probable requirements changes effecting message structure. Bindings might look something like this:
step1.exchange bound to step1.v1.queue with binding key step1.v1
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: Is their a benefit to using multiple topical exchanges instead of one topical exchange when your use case could work either way?
473
In RabbitMQ, there are four different types of exchanges that route the message differently using different parameters and bindings setups. Clients can create their own exchanges or use the predefined default exchanges which are created when the server starts for the first time.
YES, it can. A queue can have any number of bindings to different exchanges, even multiple bindings to the same exchange with different parameters.
In RabbitMQ, a producer never sends a message directly to a queue. Instead, it uses an exchange as a routing mediator. Therefore, the exchange decides if the message goes to one queue, to multiple queues, or is simply discarded.
I simply copy some key fragments for you.
https://spring.io/blog/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/
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 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
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
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
198
Take a look at "Routing Topologies for Performance and Scalability with RabbitMQ" http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/
42
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
