<div class="wiki-content maincontent"><p>Clustering is a large topic and often means different things to different people. We'll try to list the various aspects of clustering and how they relate to ActiveMQ</p><h2>Queue consumer clusters</h2><p>ActiveMQ supports reliable high performance load balancing of messages on a queue across consumers. In enterprise integration, this scenario is known as the&#160;<a shape="rect" href="http://www.eaipatterns.com/CompetingConsumers.html">competing consumers</a> pattern. The following figure illustrates the concept:</p><p><image ac:align="center"><attachment ri:filename="competing-consumers.png"></attachment></image></p><p><span style="line-height: 1.4285715;">This solution receives the messages sent by the producers, enqueues them and distributes them between all the registered consumers. This has a number of benefits:</span></p><ul><li><span style="line-height: 1.4285715;">The load is distributed in a very dynamic fashion. Additional consumers could be provisioned and attached to the queue in high load periods, without modifying any configuration in the queue, as the new consumer would behave as just another competing consumer.</span></li><li><span style="line-height: 1.4285715;">Better availability than systems using a load balancer. Load balancers usually rely on a monitorization system to find out which real-servers are unavailable. With competing consumers, a failed consumer won't be competing for messages and therefore messages won't be delivered to it even without monitorization.</span></li><li>High reliability, if a consumer fails, any unacknowledged messages are redelivered to other consumers on the queue.</li></ul><p>On the downside, this pattern might not be ideal in systems where the order processing is required. To mitigate this problem while maintaining the benefits, the competing consumers pattern should be used in conjunction with other ActiveMQ&#160;<link><page ri:content-title="Features"></page><plain-text-link-body>features</plain-text-link-body></link>&#160;like the <link><page ri:content-title="Exclusive Consumer"></page><plain-text-link-body>exclusive consumers</plain-text-link-body></link> and the <link><page ri:content-title="Message Groups"></page><plain-text-link-body>message groups</plain-text-link-body></link>&#160;as stated in the <link><page ri:content-title="How do I preserve order of messages"></page><plain-text-link-body>ActiveMQ's FAQ</plain-text-link-body></link>.</p><h2>Broker clusters</h2><p>The most common mental model of clustering in a JMS context is that there is a collection of JMS brokers and a JMS client will connect to one of them; then if the JMS broker goes down, it will auto-reconnect to another broker.</p><p>We implement this using the <strong>failover://</strong> protocol in the JMS client. See the <link><page ri:content-title="Failover Transport Reference"></page></link> page for details of how to configure the failover protocol. <em>Note:</em> The reliable:// protocol in ActiveMQ 3.x has now been changed to the failover:// protocol</p><p>If we just run multiple brokers on a network and tell the clients about them using either <a shape="rect" href="http://incubator.apache.org/activemq/static-transport-reference.html">static discovery</a> or <a shape="rect" href="http://incubator.apache.org/activemq/discovery-transport-reference.html">dynamic discovery</a>, then clients can easily failover from one broker to another. However, stand alone brokers don't know about consumers on other brokers; so if there are no consumers on a certain broker, messages could just pile up without being consumed. We have an outstanding <a shape="rect" href="http://issues.apache.org/activemq/browse/AMQ-816">feature request</a> to tackle this on the client side - but currently the solution to this problem is to create a Network of brokers to store and forward messages between brokers.</p><h2>Discovery of brokers</h2><p>We support <link><page ri:content-title="Discovery"></page><plain-text-link-body>auto-discovery</plain-text-link-body></link> of brokers using <a shape="rect" href="http://incubator.apache.org/activemq/static-transport-reference.html">static discovery</a> or <a shape="rect" href="http://incubator.apache.org/activemq/discovery-transport-reference.html">dynamic discovery</a>,&#160;so clients can automatically detect and connect to a broker out of a logical group of brokers as well for brokers to discover and connect to other brokers to form large networks.</p><h2>Networks of brokers</h2><p>If you are using <link><page ri:content-title="Topologies"></page><plain-text-link-body>client/server or hub/spoke style topology</plain-text-link-body></link> and you have many clients and many brokers, there is a chance that one broker has producers but no consumers, so that messages pile up without being processed. To avoid this, ActiveMQ supports a <link><page ri:content-title="Networks of Brokers"></page></link> which provides <em>store and forward</em> to move messages from brokers with producers to brokers with consumers which allows us to support <link><page ri:content-title="How do distributed queues work"></page><plain-text-link-body>distributed queues and topics</plain-text-link-body></link> across a network of brokers.</p><p>This allows a client to connect to any broker - and fail over to another broker if there is a failure - providing a cluster of brokers&#160;from the clients perspective.</p><p>Networks of brokers also allows us to scale up to a massive number of clients in a network as we can run as many brokers as we need.</p><p>You can think of this as a cluster of clients connecting with a cluster of brokers with auto-failover and discovery, making a simple and easy to use messaging fabric.</p><h2>Master Slave</h2><p>The problem with running lots of stand alone brokers or brokers in a network is that messages are owned by a single physical broker at any point in time. If that broker goes down, you have to wait for it to be restarted before the message can be delivered. (If you are using non-persistent messaging and a broker goes down you generally lose your message).</p><p>The idea behind <link><page ri:content-title="MasterSlave"></page></link> is that messages are replicated to a slave broker so that even if you have a catastrophic hardware failure of the master's machine, file system or data centre, you get immediate failover to the slave with no message loss.</p><h2>Replicated Message Stores</h2><p>An alternative to <link><page ri:content-title="MasterSlave"></page></link> is to have some way to replicate the message store; so for the disk files to be shared in some way. For example using a SAN or shared network drive you can share the files of a broker so that if it fails another broker can take over straight away.</p><p>So by supporting a <link><page ri:content-title="Replicated Message Store"></page></link> you can reduce the risk of message loss to provide either a HA backup or a full <link><page ri:content-title="DR"></page></link> solution capable of surviving a data centre failure.</p></div>