[rabbitmq-discuss] Round-robin queue failover

Mon Oct 26 16:23:27 GMT 2009

Sebastian

On Mon, Oct 26, 2009 at 4:04 PM, Sebastian <mail at sebastian-latza.de> wrote:
>
> Kyle Schaffrick:
>
>> Attempting to create two identically-named queues will
>> result in declaring the same queue twice; the two consumers then
>> consuming from that queue will see load-balancing behavior.
>
> Thanks for the clarification. Since this does not work: how do I
> achieve reliable persistent message delivery even if the one node
> holding the queue dies?

At the risk of being seen as pedantic...

You could achieve it by waiting for the node to recover from disk.  In
other words: RabbitMQ provides "eventual delivery" out of the box.  If
you want to 'persist more reliably' than on one drive using RabbitMQ
out of the box, then use a RAID or a SAN.

I am guessing that what you mean is *availability* in which a message
can always reach a suitable queue even if the sending client loses its
connection with the node that crashed.  The problem with using a
single node is the time it takes to recover, and client reconnection
costs (if any).  The time to recover is partly influenced by how much
state has to recover, and partly by the size of the unavailability
window that you can tolerate.

Many applications don't like to wait more than (say) 1ms, 10ms or 50ms
before they can send their message.  In this case you will typically
want to send a message *before* the crashed node has been able to
recover.  You can achieve this in two ways:

1. You don't care about replicating state and can use any other queue
as a 'suitable queue'.  This is easy - just make sure the right
consumers and routes are wired up.

2. You do care about replicating state - which I think is the case you
have in mind.  Then you can fail over to a passive server.  We can
provide some more info on this if you like -- we have done it for a
few people but it is not yet 'available OOTB'.  (You can also do
active/active but it is much more fiddly atm).

> As stated before my take would be to replicate
> queues client-side on independent brokers, but this seems to be
> getting quite complicated as the queues have to be "double-declared",
> linked and properly re-initialized on startup of a new empty broker
> (basically doing some kind of client-side clustering).

Right.  I think you probably want case 2 above.

alexis

> Regards
> Sebastian
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>