Interesting feature I didn’t know about, but I’d probably look at etcd or zookeeper for distributed locking. I actually haven’t seen an architecture that included multiple instances of rabbitmq, every time it’s just one queue, a single point of failure.
IMO, RabbitMQ clustering does not handle network partitions well. It possibly requires a human to decide which RabbitMQ is golden.
RabbitMQ supports “autoheal” mode for clustering: https://www.rabbitmq.com/partitions.html
And the semantics of “autoheal” are absolutely terrifying.
You are always welcome to suggest improvements for RabbitMQ. Here’s our mailing list: https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
I think the overall semantics of RabbitMQ clustering make providing a reasonable alternative extremely difficult. Instead I prefer to simply not make use of clustering and use Rabbit has a transport.
Have you been following the news?
See the New York Times architecture for example, completely distributed around many RabbitMQ Instances:
Instagram uses a lot of RabbitMQ, many more companies do. There are many use cases cited on the Pivotal blog, but I don’t want to get “commercial” in this forum.
It’s worth pointing out that “having a single point of failure” has nothing to do with RabbitMQ or any other software tech for that matter, it’s about how whoever setup that architecture decided to go about each software component.