ActiveMq集羣技術

http://blog.csdn.net/neutrojan/article/details/8921533

ActiveMQ集羣

       ActiveMQ具備強大和靈活的集羣功能，但在使用的過程當中會發現不少的缺點，ActiveMQ的集羣方式主要由兩種：Master-Slave和Broker Cluster。

一、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，以下：

Xml代碼  

1. <broker xmlns="http://activemq.apache.org/schema/core" brokerName="pure_slave" masterConnectorURI="tcp://0.0.0.0:61616" shutdownOnMasterFailure="false" dataDirectory="${activemq.base}">  

同時修改Slave的服務端口，如：

Xml代碼  

1. <transportConnectors>  

2.            <transportConnector name="openwire" uri="tcp://0.0.0.0:61617"/>  

3. </transportConnectors>  

爲了看到實踐的效果，Master和Slave的消息持久化介質都是採用MySQL，而且Master和Slave分別鏈接不一樣的數據庫。

   在消息生產者應用和消息消費者應用的Spring配置文件中添加如下紅色內容：

Xml代碼  

1. <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的配置文件作一些簡單的配置，就是把持久化適配器的存儲目錄改成本地磁盤的一個固定目錄，三個實例共享這個目錄，以下：

Xml代碼  

1. <span style="color: #ff0000;"><persistenceAdapter>  

2.    <kahaDB directory="E:/XXX/XXX/XXX/cluster/shared_file/data/kahadb" />  

3. </persistenceAdapter></span>  

而後修改ActiveMQ實例的服務端口和jetty的服務端口，防止端口占用異常。啓動三個ActiveMQ實例，就能夠進行測試了。

   以上配置只能在一臺機器進行，若是各個ActiveMQ實例須要運行在不一樣的機器，就須要用到分佈式文件系統了。

（3）JDBCMaster Slave

       JDBCMaster Slave模式和Shared File Sysytem Master Slave模式的原理是同樣的，只是把共享文件系統換成了共享數據庫。咱們只需在全部的ActiveMQ的主配置文件中（${ACTIVEMQ_HOME}/conf/activemq.xml）添加數據源，全部的數據源都指向同一個數據庫，如：

Xml代碼  

1. <bean id="mysql-ds" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">  

2.        <property name="driverClassName" value="com.mysql.jdbc.Driver"/>  

3.        <property name="url" value="jdbc:mysql://localhost:3306/cluster_jdbc?relaxAutoCommit=true"/>  

4.        <property name="username" value="root"/>  

5.        <property name="password" value="root"/>  

6.        <property name="maxActive" value="200"/>  

7.        <property name="poolPreparedStatements" value="true"/>  

8. </bean>  

而後修改持久化適配器。這種方式的集羣相對Shared File System Master Slave更加簡單，更加容易地進行分佈式部署，可是若是數據庫失效，那麼全部的ActiveMQ實例都將失效。

   以上三種方式的集羣都不支持負載均衡，但能夠解決單點故障的問題，以保證消息服務的可靠性。

二、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實例，如：

Xml代碼  

1. <span style="color: #ff0000;"><networkConnectors>  

2. <networkConnector uri="static:failover://(tcp://localhost:61616)" duplex="true" />  

3. </networkConnectors></span>  

上面這段配置須要加在<persistenceAdapter>節點的前面。而後在消費者應用中設置brokerURL的值如：

Xml代碼  

1. <property name="brokerURL" value="<span style="color: #ff0000;">failover:(tcp://localhost:61617)</span>?initialReconnectDelay=100" />  

       Static Discovery集羣方式有些缺點，如不能解決單點故障問題，若某個Broker失效時，有可能形成數據的丟失，動態添加節點不夠智能化。

   更加詳細的說明與配置請參考：http://activemq.apache.org/networks-of-brokers.html

（2）DynamicDiscovery集羣

       DynamicDiscovery集羣方式在配置ActiveMQ實例時，不須要知道全部其它實例的URI地址，只需在全部實例的${ACTIVEMQ_HOME}/conf/activemq.xml文件中添加如下內容：

Xml代碼  

1. <span style="color: #ff0000;"><networkConnectors>  

2. <networkConnector uri="multicast://default" />  

3. </networkConnectors></span>  

同時在<transportConnectors>節點中添加如下紅色部份內容：

Xml代碼  

1. <transportConnectors>  

2. <transportConnector name="openwire" uri="tcp://0.0.0.0:61616" <span style="color: #ff0000;">discoveryUri="multicast://default"</span> />  

3. </transportConnectors>  

這樣就能夠實現消息在全部ActiveMQ實例之間進行路由。Dynamic Discovery集羣方式的缺點和Static Discovery同樣。

   從以上的分析能夠看出，Master-Slave模式不支持負載均衡，但能夠經過消息的實時備份或共享保證消息服務的可靠性，Broker Cluster模式支持負載均衡，能夠提升消息的消費能力，但不能保證消息的可靠性。因此爲了支持負載均衡，同時又保證消息的可靠性，咱們能夠採用Msater-Slave+Broker Cluster的模式。