ActiveMQ集羣
ActiveMQ具有強大和靈活的集羣功能，但在使用的過程中會發現很多的缺點，ActiveMQ的集羣方式主要由兩種：Master-Slave和Broker Cluster。
1、Master-Slave
Master-Slave方式中，只能是Master提供服務，Slave是實時地備份Master的數據，以保證消息的可靠性。當Master失效時，Slave會自動升級爲Master，客戶端會自動連接到Slave上工作。Master-Slave模式分爲三類：Pure Master Slave、Shared File System Master Slave和JDBC Master Slave。
（1）PureMaster Slave
需要兩個Broker，一個作爲Master，另一個作爲Slave，運行時，Slave通過網絡實時從Master處複製數據，同時，如果Slave和Master失去連接，Slave就會自動升級爲Master，繼續爲客戶端提供消息服務，如圖所示：
實踐時，我們使用兩個ActiveMQ服務器，一個作爲Master，Master不需要做特殊的配置；另一個作爲Slave，配置${ACTIVEMQ_HOME}/conf/activemq.xml文件，在<broker>節點中添加連接到Master的URI和設置Master失效後不關閉Slave，如下：
<broker xmlns="http://activemq.apache.org/schema/core" brokerName="pure_slave" masterConnectorURI="tcp://0.0.0.0:61616"
shutdownOnMasterFailure="false" dataDirectory="${activemq.base}"><transportConnectors>
<transportConnector name="openwire" uri="tcp://0.0.0.0:61617"/>
</transportConnectors>爲了看到實踐的效果，Master和Slave的消息持久化介質都是採用MySQL，並且Master和Slave分別連接不同的數據庫。
在消息生產者應用和消息消費者應用的Spring配置文件中添加以下內容：
<property name="brokerURL" value="failover:(tcp://localhost:61616,tcp://localhost:61617)?initialReconnectDelay=100" /> A、啓動Master和Slave，啓動消息生產者應用，並分別發送一些Queue消息和Topic消息，如果此時訂閱Topic消息的消費者設置了clientID，我們就可以在Master的數據庫和Slave的數據庫中看到尚未消費的消息，包括Queue和Topic的消息；
B、啓動消費者應用，可以接收到消息；
C、關閉消費者，生產者繼續發送一些消息A；
D、停止Master；
E、生產者繼續發送消息B；
F、啓動消費者應用，消費者可以接收到消息A和消息B，說明Slave接替了Master的工作並複製了Master的消息。
這種方式只能兩臺機器做集羣，可以起到很好的雙機熱備功能，但只能失效一次，只能停機恢復Master-Slave結構。
（2）SharedFile System Master Slave
SharedFile System Master Slave就是利用共享文件系統做ActiveMQ集羣，是基於ActiveMQ的默認數據庫kahaDB完成的，kahaDB的底層是文件系統。這種方式的集羣，Slave的個數沒有限制，哪個ActiveMQ實例先獲取共享文件的鎖，那個實例就是Master，其它的ActiveMQ實例就是Slave，噹噹前的Master失效，其它的Slave就會去競爭共享文件鎖，誰競爭到了誰就是Master。這種模式的好處就是當Master失效時不用手動去配置，只要有足夠多的Slave。Shared File System Master Slave模式如圖所示：
本例子是在一臺機器上運行三個ActiveMQ實例，需要對ActiveMQ的配置文件做一些簡單的配置，就是把持久化適配器的存儲目錄改爲本地磁盤的一個固定目錄，三個實例共享這個目錄，如下：
<persistenceAdapter>
<kahaDB directory="E:/XXX/XXX/XXX/cluster/shared_file/data/kahadb" />
</persistenceAdapter>然後修改ActiveMQ實例的服務端口和jetty的服務端口，防止端口占用異常。啓動三個ActiveMQ實例，就可以進行測試了。
以上配置只能在一臺機器進行，如果各個ActiveMQ實例需要運行在不同的機器，就需要用到分佈式文件系統了。
（3）JDBCMaster Slave
JDBCMaster Slave模式和Shared File Sysytem Master Slave模式的原理是一樣的，只是把共享文件系統換成了共享數據庫。我們只需在所有的ActiveMQ的主配置文件中（${ACTIVEMQ_HOME}/conf/activemq.xml）添加數據源，所有的數據源都指向同一個數據庫，如：
<bean id="mysql-ds" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName" value="com.mysql.jdbc.Driver"/>
<property name="url" value="jdbc:mysql://localhost:3306/cluster_jdbc?relaxAutoCommit=true"/>
<property name="username" value="root"/>
<property name="password" value="root"/>
<property name="maxActive" value="200"/>
<property name="poolPreparedStatements" value="true"/>
</bean> 然後修改持久化適配器。這種方式的集羣相對Shared File System Master Slave更加簡單，更加容易地進行分佈式部署，但是如果數據庫失效，那麼所有的ActiveMQ實例都將失效。
以上三種方式的集羣都不支持負載均衡，但可以解決單點故障的問題，以保證消息服務的可靠性。
2、BrokerCluster
Broker Cluster主要是通過network of Brokers在多個ActiveMQ實例之間進行消息的路由。Broker的集羣分爲Static Discovery和Dynamic Discovery兩種。
（1）StaticDiscovery集羣
Static Discovery集羣就是通過硬編碼的方式使用所有已知ActiveMQ實例節點的URI地址。如：消息生產者應用連接一個ActiveMQ實例，我們暫時稱爲MQ1，所有的消息都由該實例提供；兩個消息消費者應用分別連接另外兩個ActiveMQ實例，分別爲MQ2和MQ3，兩個消息消費者需要消費MQ1上的消息，但它們連接的都不是MQ1，可以通過Static Discovery方式把MQ1上的消息路由到MQ2和MQ3，爲了保證消費者不因某個節點的失效而導致不能消費消息，在消費者應用中需要配置所有節點的URI。
生產者ActiveMQ實例不需要特殊的配置，所有的消費者ActiveMQ實例需要添加networkConnectors節點，連接到生產者MQ實例，如：
<networkConnectors>
<networkConnector uri="static:failover://(tcp://localhost:61616)" duplex="true" />
</networkConnectors>然後在消費者應用中設置brokerURL的值如：
<property name="brokerURL" value="failover:(tcp://localhost:61617)?initialReconnectDelay=100" /> 更加詳細的說明與配置請參考：http://activemq.apache.org/networks-of-brokers.html
（2）DynamicDiscovery集羣
DynamicDiscovery集羣方式在配置ActiveMQ實例時，不需要知道所有其它實例的URI地址，只需在所有實例的${ACTIVEMQ_HOME}/conf/activemq.xml文件中添加以下內容：
<networkConnectors>
<networkConnector uri="multicast://default" />
</networkConnectors><transportConnectors>
<transportConnector name="openwire" uri="tcp://0.0.0.0:61616" discoveryUri="multicast://default" />
</transportConnectors> 這樣就可以實現消息在所有ActiveMQ實例之間進行路由。Dynamic Discovery集羣方式的缺點和Static Discovery一樣。
從以上的分析可以看出，Master-Slave模式不支持負載均衡，但可以通過消息的實時備份或共享保證消息服務的可靠性，Broker Cluster模式支持負載均衡，可以提高消息的消費能力，但不能保證消息的可靠性。所以爲了支持負載均衡，同時又保證消息的可靠性，我們可以採用Msater-Slave+Broker Cluster的模式。
轉自：http://bh-keven.iteye.com/blog/1617788
參考：