[rabbitmq-discuss] Federation Topologies & Limitations
michael.laing at nytimes.com
Thu Jan 16 00:03:26 GMT 2014
Not seeing any other answers (yet)...
We have experimented with many topologies and have tried federation, but
the design that has proven the most rugged and simplest and is in
production uses shovels.
We have a core cluster that runs an exchange: the 'postoffice', This
cluster has a 'well-known' address so the retail instances can find it.
Each retail instance that comes up creates and runs 2 shovels:
1) the shovel from the core defines a source queue in the core with an
instance identifier, e.g. 'outbox_i-12345', and a binding to the core
postoffice exchange including that identifier (its address - more about
2) the shovel to the core uses the instance's 'outbox' queue as source,
which is bound to the instance postoffice exchange and specifies the
destination exchange as postoffice.
We use 'addresses' as routing and binding keys. Our addresses have 3 parts:
'action', 'from_address', 'to_address'. The parts are separated by periods.
Each address has parts: we use 'region', 'product', 'service',
'instance_id', 'pid'. Also separated by periods.
Hence the 'address' of a retail instance is, e.g.:
action: any action => *
region: from any => * (the postoffice actually spans multiple regions)
product: from any => * (identifies an internal customer)
service: from any => * (an app or a level of service)
instance: from any => *
pid: from any => *
region: mine => us-west-2
product: for any => *
service: for any => *
instance: mine => i-12345
pid: for any => *
So that is: '*.*.*.*.*.*.us-west-2.*.*.i-12345.*' meaning the instance will
accept anything sent to its region and instance-id.
A typical routing key might be:
meaning that a service running on a particular pid in another instance is
sending our instance a message for a different service, same product, on an
There should be an app queue bound to the postoffice on the instance with
an appropriate key to receive the message.
We have standard routines, of course, to handle the creation and
manipulation of keys. Plus our deployments are automated - so all those
asterisks are quite easy to handle in practice although a little hard to
And of course you can come up with your own addressing scheme to match your
requirements that could be simpler.
This is just a straightforward bus implementation, made possible by the
flexibility of the RabbitMQ routing/binding scheme. We have found it very
useful and have extended the 'postoffice' across all of our instances in
multiple regions with good result.
On Wed, Jan 15, 2014 at 2:19 PM, Josh West <jsw at one.com> wrote:
> Hi folks,
> I'm currently working with the federation plugin in order to connect
> potentially 100-200 different brokers. The purpose is to provide a virtual
> message bus, where systems on any broker can send messages to other systems
> that are likely connected to a different broker. Basically, a communication
> network / message bus.
> I am experimenting with different architectures and it seems that in order
> to prevent message duplications, I'll have to go with a complete graph and
> max-hops set to 1 -- or in other words, each broker will have to directly
> federate with the other 100-200 brokers.
> I'm wondering about the limitations (if they exist) of the federation
> plugin or this style of architecture. There isn't much information out
> there on the pro's and con's of different topologies (aside from obvious
> issues with a large ring topology).
> Can anybody elaborate or add any input?
> Josh West
> One.com - http://www.one.com
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss