-
Notifications
You must be signed in to change notification settings - Fork 21
RabbitMQ queues failover
I believe some client libraries in different languages have already supported RabbitMQ failover such as Spring in Java, but not much .NET client library does that. Hopefully this is what you looking for.
I personally don't think Alternate Exchanges is a good solution. Don't you really have your exchanges and queues bind together properly before publishing, especially in an important project? I usually have everything setup properly and the only reason that can stop my applications from working is when the RabbitMQ server is actually down. We have a system that eliminates all single point of failure, the RabbitMQ server is the last one that potentially causes problem.
I did some research on google, some folks use HAProxy in front of a cluster of RabbitMQ nodes. Again, I don't think it's a good idea as this still introduces another single point of failure no mater how well and stable HAProxy is. So to me it came down to a traditional solution where application should know about all nodes in a cluster. When a node down, the application should be able to fail over to next node, and that's whay Burrow.NET tries to archive since version 1.0.18
We currently have a single RabbitMQ server running on Ubuntu with only 4GB Ram. It's been running pretty well in several months without any single down time. The only problem we got in the past was when our consumers did not consume fast enough. Eventually, the server overwhelmed with messages and it blocked all connections. Anyway, we want to stop that sittuation and change to make a cluster of 3 nodes, each node has 16GB RAM so i'm pretty sure about the stabability in the future. I think the third node might be not really necessary though.
Asume that you have your cluster setup correctly, what you need to do is very simple.
Update to Burrow.NET version >= 1.0.18 and change your connection string in config file to something like below:
host=ip1.com;username=guest;password=guest|host=ip2.com;username=guest;password=guest|host=ip3.com;username=guest;password=guest
That's it. Burrow.NET will take care of the problem and fail over to whatever node alive.
Cheers