<div dir="ltr">Matthias,<div><br></div><div>Imagine the following scenario:<br><br>There are four servers named rmq01, rmq02, rmq03, and rmq04. Servers rmq01 and rmq02 are clustered; servers rmq03 and rmq04 are clustered (so we now have 2x two node clusters).</div>
<div><br></div><div style>On both clusters we create a vhost named &quot;default&quot;, a direct exchange named &quot;default&quot;, a queue named &quot;default&quot;, a user &quot;default&quot; (which has read, write and config access to the aforementioned objects) with a password of &quot;default&quot; and apply the ha-all mode to the &quot;default&quot; vhost.</div>
<div style><br></div><div style>We place these two identically configured clusters inside of a load balanced pool with a &quot;least queue depth&quot; configuration. We then configure the consumers and producers associated with this app to connect to the VIP (which maps to the load balanced pool) to send messages to the &quot;default&quot; exchange and consume messages from the &quot;default&quot; queue.</div>
<div style><br></div><div style>Assuming we have more producers and consumers than we do RabbitMQ nodes (and they get distributed properly), we&#39;ve now increased our throughput - as we now have two master queue processes to work with on this &quot;single&quot; queue.</div>
<div style><br></div><div style>Regards,</div><div style><br></div><div style>Richard</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 19, 2013 at 2:59 PM, Matthias Radestock <span dir="ltr">&lt;<a href="mailto:matthias@rabbitmq.com" target="_blank">matthias@rabbitmq.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 19/03/13 21:55, Richard Raseley wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The relevance lies in the fact that the design of this particular<br>
application component relies on a single highly available queue bound to<br>
a single exchange. My thought (which you&#39;ve mostly confirmed) was that<br>
if I create multiple clusters with mirrored configurations (e.g. same<br>
exchanges, queues, users, etc.) and place those in a single load<br>
balanced pool I will be able to scale my performance (while maintaining<br>
high availability for all messages) whereas if I add additional nodes to<br>
a cluster I will not - as all operations will happen via the mater queue<br>
process which resides on exactly one node.<br>
</blockquote>
<br></div>
But your &quot;*single* highly available queue&quot;, can only live in one cluster, since it&#39;s a *single* queue. So I don&#39;t see how extra clusters help here.<span class="HOEnZb"><font color="#888888"><br>
<br>
Matthias.<br>
</font></span></blockquote></div><br></div>