ActiveMQ的集羣方式主要由兩種：Master-Slave和Broker Cluster。
我們在ActiveMQ集羣（一） —— Master-Slave 中，介紹了Master-Slave，發現了Master-Slave方式都是在解決單點故障的問題，以保證消息服務的可靠性。其Slave服務都是在同步備份數據，只有Master服務宕機後，Salve才成爲Master進行服務，即Master-Slave方式不支持負載均衡。
今天我們介紹的ActiveMQ的另外一種集羣方式——Broker Cluster，就是用於ActiveMQ集羣的負載均衡處理的，但是不幸的是，Broker Cluster雖然支持負載均衡，但是它無法保證消息服務的可靠性，存在單點故障的問題。
在Broker-Cluster部署方式中，各個Broker通過網絡互相連接，並共享queue。即當BrokerA上面指定的queue-A中接收到一個message處於pending狀態，而此時如果沒有consumer連接BrokerA時。但是如果cluster中的BrokerB上面由一個Consumer可以消費queue-A的消息，那麼BrokerB會先通過內部網絡獲取到BrokerA上面的message，並通知自己的Consumer來消費。
Broker的集羣分爲Static Discovery和Dynamic Discovery兩種。
Static Discovery
Static Discovery集羣就是通過硬編碼的方式使用所有已知ActiveMQ實例節點的URI地址。如：消息生產者應用連接一個ActiveMQ實例，我們暫時稱爲MQ1，所有的消息都由該實例提供；兩個消息消費者應用分別連接另外兩個ActiveMQ實例，分別爲MQ2和MQ3，兩個消息消費者需要消費MQ1上的消息，但它們連接的都不是MQ1，可以通過Static Discovery方式把MQ1上的消息路由到MQ2和MQ3，爲了保證消費者不因某個節點的失效而導致不能消費消息，在消費者應用中需要配置所有節點的URI。
在構成集羣的ActiveMQ實例的配置文件中添加<networkConnectors>節點，連接到生產者MQ實例。比如集羣中有四臺服務器，分別在端口 61616，61617，61618，61619提供服務，在我們的設計中61616，61617即可以是生產者也可以是消費者，而61618、61619專爲消費者服務，則端口爲61618和61619的服務器應該在配置文件的<broker>節點中增加61616，61617信息，以用來獲取61616，61617服務中的消息，如下：
<networkConnectors>節點默認在需要轉發消息時是單向連接的。當duplex=true時，就變成了雙向連接，這時配置在broker2端的指向broker1的duplex <networkConnectors>，相當於即配置了broker2到broker1的網絡連接，也配置了broker1到broker2的網絡連接。
其實的配置和我們最基礎的配置一樣，然後就可以啓動這四臺服務器了，如下：
啓動完成後，我們就可以在代碼中進行測試了，首先我們啓動兩個消息的生成者，分別連接61616、61617，然後向其test.queue目的地進行發送消息，如下：
然後我們在啓動兩個消費者，連接61618、61619，然後一個進行消費test.queue2、一個進行消費test.queue，這樣肯定是一個有消息，一個沒消息
這裏我們還可以更多的情況，如果61618、61619都配置test.queue那麼就是兩個分攤消息；如果61616、61617服務上，本身也存在消費者test.queue，那麼就三個消費者進行分攤消息。
上述配置即測試代碼主要就是上述所介紹的了，這裏我們還要再提醒一下，由於我們需要啓動多個ActiveMQ服務，不僅需要注意上述的端口問題，這裏我們一定不要忘記了給每個ActiveMQ服務的配置文件activemq.xml的<broker>標籤中 brokerName 進行命名，不然可能就不會出現我們預想中的結果了，如下：
然後我們進行測試（其餘各種情況大家可以自行測試），結果如下：
Dynamic Discovery
上述我們採用Static Discovery的方式配置集羣，有個問題就是我們事先就必要清楚所有ActiveMQ服務的地址，然後再根據業務要求進行配置。
而Dynamic Discovery集羣方式在配置ActiveMQ實例時，不需要知道所有其它實例的URI地址，只需在所有實例的activemq.xml文件中添加以下配置即可
按照上述我們把所有的ActiveMQ服務配置好，然後就可以進行測試了，這裏我們就來測試一種不同的情況，如兩個生成者還是像61616、61617服務上生成消息
但是消息的消費者61618、61618服務上的test.queue，所以這裏的測試結果應該是分攤消息
運行測試結果如下：
