[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
reason)
- 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