RabbitMq clustering and scalability

[R.Waldez]

Hello Everyone,

I want to build scalable RabbitMq system. I have gone through its official documentation. it seems clustering with HA-mirrored queues contradicts scalability as adding more nodes deteriorates performance.I mean, If I have clustered system of (let's say) 3 nodes, how can clustering (without HA policy enabled) help increase throughput as opposed to having a system with 3 disconnected node?

Thanks in advance.

[R.Waldez]

and if clustering is not just for mirroring, how can it increase scalability? why use it then?

[Michael Klishin]

Mirroring means N nodes have to do repetitive work, which does not help scalability. You don't have to

mirror every queue and to all nodes, however, as the docs try to explain.

One very obvious limitation of a single node is how many connections it can sustain [1].

Managing N independent nodes is harder. Lastly, message replication would require apps specifically developed to do that.

Those are the primary reasons.

1. https://www.rabbitmq.com/networking.html#tuning-for-large-number-of-connections

On Thu, Jun 7, 2018 at 12:03 PM, R.Waldez <wald...@gmail.com> wrote:

and if clustering is not just for mirroring, how can it increase scalability? why use it then?

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

MK

Staff Software Engineer, Pivotal/RabbitMQ

[R.Waldez]

Hi Karl,

Thanks for responding.

In N independent nodes configuration, if there is no mirroring and synchronization work between nodes. why is managing N independent nodes harder? 

consider 3 independent nodes with some load-balancing strategy behind them to increase throughput (perhaps some randomizer application in round-robin fashion). what is the benefit of using clustering in this scenario? 
some advice on using federated queues or sharding to increase throughput. would be much appreciated.

On Thursday, June 7, 2018 at 2:11:09 PM UTC+4:30, Michael Klishin wrote:

Mirroring means N nodes have to do repetitive work, which does not help scalability. You don't have to

mirror every queue and to all nodes, however, as the docs try to explain.

One very obvious limitation of a single node is how many connections it can sustain [1].

Managing N independent nodes is harder. Lastly, message replication would require apps specifically developed to do that.

Those are the primary reasons.

1. https://www.rabbitmq.com/networking.html#tuning-for-large-number-of-connections

On Thu, Jun 7, 2018 at 12:03 PM, R.Waldez <wald...@gmail.com> wrote:

and if clustering is not just for mirroring, how can it increase scalability? why use it then?

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To post to this group, send email to rabbitm...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Michael Klishin]

I am not Karl but will answer nonetheless.

The hard part is the "synchronization work". Most users expect the data service to do most if not all the heavy lifting there.

If you have reasons to use individual nodes, go for it. 

Your application complexity will go up significantly but in a way you will have more control.

Staff Software Engineer, Pivotal/RabbitMQ

[anup anand]

Below is a recent post by me on seeking similar information:

https://groups.google.com/forum/m/#!topic/rabbitmq-users/pghelnGuYRc

Have given an overview of the architecture that I have currently. Let me know if it helps in this discussion.

Thanks

Anup

[R.Waldez]

Thanks Michael, sorry for the Karl part

[R.Waldez]

what load balancing strategy (federated queues or sharding) will be best to increase throughput?

[Michael Klishin]

Sharding is used in clusters, federated queues assume loosely coupled instances or clusters. Sharding is more predictable and less dependent on consumer locality.

Both can achieve the goal but they work very differently.

On 7 Jun 2018, at 15:34, R.Waldez <wald...@gmail.com> wrote:

what load balancing strategy (federated queues or sharding) will be best to increase throughput?

--

[R.Waldez]

With regard to limitation of connections for single node, consider that there are 3 brokers (B1,B2,B3) deployed in a clustered model with 3 queues (Q1,Q2,Q3) all defined on B1. if consumers connect to any of nodes, they will actually end up consuming from the master node.So the B1 should handle all connections from all clients.

Isn't this equivalent to the case all the clients connecting and consuming from the B1 in the first place ? 

does clustering provide added benefit ?

[Karl Nilsson]

Hi,

Clustering will allow you to accept more connections and host more (non-ha) queues assuming they are spread across the cluster. Consequently you should also be able to get more total throughput. In addition it will provide higher availability of the service although naturally you run a higher risk of queue data being lost if it isn't mirrored and you lose a RabbitMQ node. 

It is worth noting that a single queue is roughly analogous to a single thread in terms of processing. More queues means more parallelism and you should design your systems that use RabbitMQ with this in mind.

Cheers

Karl

--

[R.Waldez]

Hi Karl,

Thanks for the reply. 

you said that single queue is roughly analogous to a single thread, does it mean that if I add more queues on a single machine and leverage the power of multi-core processors, I can achieve more scalability?

[Michael Klishin]

The runtime will be able to use more cores. Whether that translates to "more scalability" depends on how you define it.

To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.