[rabbitmq-discuss] HELP: Replication vs RabbitMQ persistence in production environment

Mat Burton matburton at gmail.com
Wed Mar 26 12:49:21 GMT 2014

Hey Nikolay,

Where I work we've opted to put a RabbitMQ broker on each physical machine 
in our live environment.
These brokers have a single exchange and queue both called "local.outgoing" 
(i.e. there's a single message stream)

There is then a central RabbitMQ broker with shovels configured to fetch 
messages from each machine.
The central RabbitMQ broker is where all the routing to queues takes place.

This means that:

   - It's unlikely that the local RabbitMQ broker instance is unreachable
   - Messages are queued at the local RabbitMQ broker if there are network 
   problems until they're resolved
   - Apps don't have to maintain state (unless they need to for another 
   - Apps are dumb, they just raise events (messages) but don't know who 
   cares and who they should send messages to, it's one big stream
   - We can upgrade, restart, re-configure the central RabbitMQ broker as 
   required without down-time or message loss

This is just a case study ;-) it may not match you're requirements
Mat B

On Saturday, 15 March 2014 16:18:49 UTC, Nikolay Maximov wrote:
> Hi,
> Please share you experience in architecture setup. Current application 
> setup built as local SQL database filled in realtime with rate as fast as 1 
> transaction per 10 seconds. There are a few tables to replicate - one from 
> point of sale transaction and another with image. This is 2-tier scheme 
> with collecting data from 15-40 nodes (points of sale). Data then 
> replicated to 2nd level with SymmetricDS software. We want to move to MQ 
> architecture and I want to ask wether this is good solution? I found no 
> information on how to protect RabbitMQ from node failures or network down 
> problems. Current solution store data in node's MySQL database until 
> network is up and them SymmetricDS detects difference to be sent to upper 
> layer.
> Any help is appreciated. Thank you in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20140326/34d57dc9/attachment.html>

More information about the rabbitmq-discuss mailing list