[rabbitmq-discuss] HELP: Replication vs RabbitMQ persistence in production environment
matburton at gmail.com
Wed Mar 26 12:49:21 GMT 2014
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
On Saturday, 15 March 2014 16:18:49 UTC, Nikolay Maximov wrote:
> 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
> Any help is appreciated. Thank you in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss