[rabbitmq-discuss] single broker and queue scalability question

justin.adam.miller at gmail.com justin.adam.miller at gmail.com
Fri Jul 29 19:30:57 BST 2011

I have an app that will have, at any one time, < 500 connections to a
single broker, across multiple machines, all of whom I want as
consumers of one queue so that rabbit can load balance amongst them.

Is handling so few connections/consumers a joke for rabbit? Should I
consider clustering, and if so, what does clustering buy me in this
case? The one thing I don't love about clustering is that, without
active/passive failover, the node that declares the queue is a single
point of failure.

The idea of clustering along with multiple queues bound to one
exchange is appealing (since exchange and binding information is
replicated across the cluster), but rabbit will not round robin
messages to all the bound queues -- there's no exchange type (that I
know of) that has that behavior.

If I knew the bound queues ahead of time, then I could pick one at
random, but it seems like determining that queue would be cumbersome,
inefficient and/or costly at best.


More information about the rabbitmq-discuss mailing list