[rabbitmq-discuss] Clustering

Alexis Richardson alexis.richardson at cohesiveft.com
Sat Nov 3 11:21:14 GMT 2007

On 11/3/07, Matthias Radestock <matthias at lshift.net> wrote:
> You can guarantee exactly-once delivery if you use transactions, durable
> queues and exchanges, and persistent messages, but only as long as any
> failing node eventually recovers.
> If you can afford to lose the odd message then the simplest setup is to
> just have consumers detect when connections goes down, connect to the
> other node and recreate their queues. Similarly, producers just
> re-connect to the second node on failure of the first node, and start
> sending messages to the same exchange as before.
> If message loss is bad but duplication is ok then you can could set up
> two parallel routing topologies with producers sending messages to both
> nodes and each consumer consuming from two queues - one on each node.
> There are various other options; which one is best really depends on the
> specific requirements of your application.

All true.

Another MQ-like pattern that works for 0-8/0-9, for some cases, is
applicable when message loss is bad, and 'eventual delivery' is
desired. If you have a local disk, then run a second broker on the
client machine, in persistent mode.  Then, write a consumer which
copies messages from the local broker on the client, to the broker on
the server.  This may feel clunky but it lets the client application
'hand off' delivery to the local queue reliably, provided that the
local disk can be trusted.  Then delivery to the server and hence to
the ultimate message recipient will eventually occur assuming there is
a network.

As Matthias pointed out these patterns for reliability, though
possible today, will be supported better in 0-10.


More information about the rabbitmq-discuss mailing list