ActiveMQ 集羣

1、ActiveMQ 集羣(1)

Queue consumer clusters(消費者集羣)：

　　簡介： 同一個queue，如果一個消費者失效, 那麼任何未經確認的消息將會被髮送給queue上的其它消費者。如果一個消費者比其它消費者執行的更快，它將會消費更多的消息。如果任何一個消費者執行速度變慢，那麼其他消費者將來彌補空缺。所以，消費者在(隊列中)處理消息時，可以有一個可靠的負載均衡。

　　實現原理: 消費者對消息的處理速率可能不同,對於broker而言,它無法意識到哪個消費者處於"空閒"狀態,故消費者空閒時主動向broker請求消息,如此還能有一個良好的"負載均衡".

　　消費者集羣不需要特殊的配置，即可使用。

　　消費者集羣，主要用於解決 消費者間的負載均衡。 

 

Broker clusters(MQ集羣) 

 　　簡介： 一個client連接多臺broker中的一臺(brokerA)。如果brokerA 掛了，那麼client可自動重新連接到其它的 broker(brokerB)上。但是，brokerB並不會識別其它broker上的消費者，如果brokerB沒有可識別的消費者，那麼brokerB上的消息會因爲得不到處理而被堆積起來。 

　　目前的解決方案是使用 Network of brokers，在brokers之間實現存儲轉發消息。 

有2種方式實現 broker集羣: 

(1) 使用網絡連接(Network of brokers)方式: 

 　　網絡連接方式: 通過把多臺不同的broker連接在一起，作爲一個整體對外提供服務，從而提高整體對外的消息服務能力。通過這種方式，brokers可以共享隊列和消費者列表，從而達到分佈式隊列的目的。 

　　 ① 可以同時運行任意多個broker和client。(broker集羣 + client集羣)

　　 ② client可連接到任意一臺broker上，若這臺broker掛了，client可自動重新連  接到另一臺broker上。 

　　 實現原理: 通過實現靜態發現或動態發現，client可以在一臺broker掛了之後，自動地監測並且連接到網絡中其它的broker上，同時，也可用於一臺broker去發現並且連接到網絡中其它的broker上。

 　　Netword of brokers的目的: 提供存儲和轉發消息到另一臺broker上，以實現broker負載均衡，提高消息處理能力。

(2) 使用Master/Slave方式: 

　　背景: 由於client屬於broker的，若某臺broker掛了，消息只能等待broker重啓後， 再被繼續消費。 

　　所以: 解決方案是，一臺broker作爲Master，一臺broker作爲Slave， 實時的把Master上的消息備份到Slave上。若Master掛了，則服務立即切換至Slave上運行。故消息不會丟失。 

　　 

那麼一個broker如何發現其它的broker呢？ 

　　通過使用靜態發現或動態發現，當某臺broker掛了時，client可以自動地監測到並且重新連接到網絡中其它的broker上。同時，利用這個協議，broker也可以發現並且連接到網絡中其它的broker上。在 ActiveMQ 中，client通過使用 failover:// 協議來實現這個功能。 

　　即: client通過使用failover://協議，若broker掛了，client會自動監測到這種情況並且重新連接到其它的broker上。 

　　　　 Broker通過使用靜態發現或動態發現，可以連接到其它的broker上。 

 

英文參考文檔：

Broker clusters: 

　　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. 

　　We implement this using the failover:// protocol in the JMS client. See the Failover Transport Reference page for details of how to configure the failover protocol.　　　　　　

　　If we just run multiple brokers on a network and tell the clients about them using either static discovery or dynamic discovery 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. Currently the solution to this problem is to create a Network of brokers to store and forward messages between brokers.

Discovery of brokers

　　 We support auto-discovery of brokers using static discovery or dynamic discovery so clients can automatically detect and connect to a broker from brokers, as well for brokers to discover and connect to other brokers.

 Networks of brokers

　　If 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 Networks of Brokers which provides store and forward to move messages from brokers with producers to brokers with consumers which allows us to support distributed queues and topics across a network of brokers.

　　This allows a client to connect to any broker - and fail over to another broker if there is a failure - providing from the clients perspective a cluster of brokers. 

　　Networks of brokers also allows us to scale up to massive number of clients in a network as we can run as many brokers as we need. 

　　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.  

 

Borker網絡連接: 

　　Networks of Brokers目的：提供存儲轉發消息到另一臺broker上。 實現負載均衡，提高消息處理能力。

 

　　附加: http://activemq.apache.org/clustering.html

2、ActiveMQ集羣(2)

 

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

1、Master-Slave方式:

　　Master-Slave方式中，只能是Master提供服務，Slave是實時地備份Master的數據，以保證消息的可靠性。當Master失效時，Slave會自動升級爲Master，客戶端會自動連接到Slave上工作。

　　Master-Slave模式分爲三類：

　　　　a、Pure Master Slave

　　　　b、Shared File System Master Slave

　　　　c、 JDBC Master Slave。 

 

　　(1) Pure Master 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}">  

 

  　　　　　　　　<!-- 同時修改Slave的服務端口，如下：--> 

　　　　　　　　<transportConnectors>  

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

　　　　　　　　</transportConnectors>   

　　　　　　</broker>

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

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

　　　　　　<property name="brokerURL" value="failover:(tcp://localhost:61616,tcp://localhost:61617)?initialReconnectDelay=100" />

　　　　這種方式只能兩臺機器做集羣，可以起到很好的雙機熱備功能，但只能失效一次，只能停機恢復Master-Slave結構。

 

　　(2) Shared File System Master Slave

　　　　介紹:  這種方式是利用共享文件系統做ActiveMQ集羣。kahaDB是ActiveMQ下默認的文件系統。

　　　　　　　　當一個AMQ實例獲得了共享文件的鎖，這個實例就成爲了Master，其它實例即爲Slave。如果這時Master掛了，其它AMQ實例會競爭共享文件的鎖，獲得鎖的就成爲Master，其它實例還是Slave。

　　　　　　　　部署時Slave沒有限制數，而且自動切換Master不需要人工干預。

　　　　　　　　官方資料：http://activemq.apache.org/masterslave.html 

　　　　　　　　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) JDBC Master Slave

　　　　JDBC Master Slave模式和Shared File Sysytem Master Slave模式的原理是一樣的，只是把共享文件系統換成了共享數據庫。我們只需在所有的ActiveMQ的主配置文件中(${ACTIVEMQ_HOME}/conf/activemq.xml)添加數據源，讓所有的數據源都指向同一個數據庫即可。

　　　　這種方式的集羣相對Shared File System Master Slave更加簡單，更加容易地進行分佈式部署，但是如果數據庫失效，那麼所有的ActiveMQ實例都將失效。 

　　　　官方資料：http://activemq.apache.org/masterslave.html

　　　　配置概述:  

　　　　　　A. 配置上，不存在Master和Slave，所有Broder的配置基本是一樣的

　　　　　　B. 多個共享數據源的Broker構成JDBC Master Slave

　　　　　　C. 給每個Broker取一個名字

　　　　　　D. 首先搶到資源（數據庫鎖）的Broker成爲Masetr

　　　　　　E. 其他Broker保持預備狀態，定期嘗試搶佔資源，運行其的Shell中清楚的顯示了這一點

　　　　　　F. 一旦Master崩潰，其他Broker嘗試搶佔資源，最終只有一臺搶到，它立刻成爲Master

　　　　　　G. 之前的Master即使重啓成功，也只能作爲Slave等待 

　　　　配置步驟:

　　　　　　1. 修改持久化適配器爲 MySQL:

　　　　　　　　<persistenceAdapter>

　　　　　　　　　　<jdbcPersistenceAdapter dataDirectory="activemq-data" dataSource="#mysql-ds"/>

　　　　　　　　</persistenceAdapter>

　　　　　　2.  在activemq.xml 添加如下代碼:

　　　　　　　　<!--配置數據源：注意是配在broker標記之外-->

　　　　　　　　<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/mq?relaxAutoCommit=true"/>  

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

　　　　　　　　　　<property name="password" value="123456"/>  

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

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

　　　　　　　　</bean>  

　　　　　　3.  修改每個broker的tcp端口。否則，該端口被佔用時會報錯。

　　　　　　　　　　Eg: <transportConnector   name="openwire"  uri="tcp://0.0.0.0:61616"/>

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

　　　　　　　　　　　　<transportConnector   name="openwire"  uri="tcp://0.0.0.0:61618"/>

　　　　　　4.  測試時，最好爲每一個Broker都起一個獨立的名字。

　　　　　　　　　　Eg:  <broker brokerName="broker_01" … />

　　　　　　5. 在 ${ACTIVEMQ_HOME}/lib中添加 MysQL驅動jar包: mysql-connector-java-5.1.7-bin.jar

　　　　　　　　　　詳情參見資料: http://blog.csdn.net/jiangxuchen/article/details/8004612

　　 

　　　　　　客戶端連接服務端代碼: 

      　　　　　　ConnectionFactory cf = new ActiveMQConnectionFactory("failover:(tcp://0.0.0.0:61616,  tcp://0.0.0.0:61617,  tcp://0.0.0.0:61618)");

　　結論：

　　　　JDBC Master Slave模式實現方式稍微複雜一點，可以實現消息的多點熱備功能，Master、Slave的交替完全是即時的，自動的，無需重啓任何broker；隊列可以實現消息的異步和點對點發送。

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

 

2、Broker Cluster

　　Broker Cluster方式主要是通過network of Brokers在多個ActiveMQ實例之間進行消息的路由。Broker的集羣分爲Static Discovery和Dynamic Discovery兩種。

　　(1) Static Discovery集羣 

　　　　Static Discovery集羣就是通過硬編碼的方式使用所有已知ActiveMQ實例的URI地址。

　　　　如：消息生產者應用連接一個ActiveMQ實例，我們暫時稱爲MQ1，所有的消息都由該實例提供；兩個消息消費者應用分別連接另外兩個ActiveMQ實例，分別爲MQ2和MQ3，兩個消息消費者需要消費MQ1上的消息，但它們連接的都不是MQ1，可以通過Static Discovery方式把MQ1上的消息路由到MQ2和MQ3，爲了保證消費者不因某個節點的失效而導致不能消費消息，在消費者應用中需要配置所有節點的URI。 

 

　　　　配置:     

　　　　　　A、生產者的broker不需要特殊的配置

　　　　　　B、修改每個broker的tcp端口

　　　　　　　　<transportConnector   name="openwire"  uri="tcp://0.0.0.0:61616"/>

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

　　　　　　　　<transportConnector   name="openwire"  uri="tcp://0.0.0.0:61618"/>

　　　　　　C. 修改每個broker的名字

　　　　　　　　Eg:   <broker brokerName="broker_01" … />

　　　　　　D. 所有的消費者的broker需要添加networkConnectors節點，用於連接到生產者的broker，如： 

　　　　　　　　<networkConnectors>  

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

　　　　　　　　</networkConnectors> 

　　　　　　　　注: 這段配置需要加在<persistenceAdapter>節點的前面。

　　　　　　 E、最後，在消費者應用中設置brokerURL的值如：

　　　　　　　　<property name="brokerURL"  value="failover:(tcp://localhost:61616)" />  

    

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

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

 

　　(2) Dynamic Discovery集羣

　　　　Dynamic Discovery集羣方式在配置broker時，不需要知道所有其它broker的URI地址，只需在所有實例的${ACTIVEMQ_HOME}/conf/activemq.xml文件中添加以下內容：

　　　　<networkConnectors>  

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

　　　　</networkConnectors> 

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

　　　　<transportConnectors>  

　　　　　　<transportConnector name="openwire" uri="tcp://0.0.0.0:61616" discoveryUri="multicast://default" />  

　　　　</transportConnectors>  

　　　　最後，注意修改每個broker的activemq.xml的broker名字和tcp端口號。這樣就可以實現消息在所有ActiveMQ實例之間進行路由。Dynamic Discovery集羣方式的缺點和Static Discovery一樣。

    

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

　　　　

3、分佈式ActiveMQ集羣

 

分佈式ActiveMQ集羣的部署配置細節：

　　官方資料：http://activemq.apache.org/clustering.html

　　基本上看這個就足夠了，本文就不具體分析配置文件了。

 

1、Queue consumer clusters：

　　同一個queue，如果一個consumer失效，那麼未被確認的消息都會被髮送到這個queue的其它consumer上。如果某個consumer處理消息比較快，那麼它將處理更多的消息。

　　Queue consumer clusters 不需要特殊的配置。

2、Master-Slave高可用性：

　　主要目的是實現AMQ的高可用性和容錯，如果某broker掛了，需要等待它重啓才能繼續處理消息。而如果消息被複制到slave上，在當master掛了時，可以直接切換到slave導致消息不會丟失。分爲3種形式：

　　(1) pure master-slave。

　　　　該方式已經逐漸被淘汰：http://activemq.apache.org/pure-master-slave.html

　　(2) Shared File System Master Slave。

　　　　官方資料：http://activemq.apache.org/masterslave.html

　　　　利用共享文件系統:當多臺機器上都部署了AMQ時，指定這些機器的一個共享的文件路徑作爲存儲。

　　　　存儲默認是基於AMQ的kahaDB(底層是文件系統)實現。

　　　　當一個AMQ實例獲得了共享文件的鎖，這個實例就成爲了Master，其它實例即爲Slave。如果這時Master掛了，其它AMQ實例會競爭共享文件的鎖，獲得鎖的就成爲Master，其它實例還是Slave。部署時Slave沒有限制數，而且自動切換Master不需要人工干預。(官方資料有詳細的過程圖片介紹)

　　(3) JDBC Master Slave。

　　　　官方資料：http://activemq.apache.org/masterslave.html

　　　　其實與Shared File System一樣，只是把共享文件系統換成數據庫作爲存儲。方便實用，但要保證數據庫的高可用性。

3、Broker Cluster中的靜態與動態發現：

　　如何讓一個broker知道網絡上的其它多個broker呢？主要分爲靜態發現和動態發現兩種類型：

　　(1) The Static Transport(靜態發現，包括failover協議)。

　　　　官網資料：http://activemq.apache.org/static-transport-reference.html

　　　　所謂靜態發現：就是將所有已知的broker uri連接時手工進行配置，對client端uri地址做相應修改。

　　　　關於failover：當一個client連接到某個broker，而這個broker掛了，客戶端就需要自動連接到網絡上其它已知的broker上。

　　　　AMQ使用failover協議實現該功能,但需要在client連接時將所有broker以硬編碼的形式進行配置。

　　　　failover協議官方資料：http://activemq.apache.org/failover-transport-reference.html

　　(2) The Discovery Transport(動態發現)。

　　　　官網資料：http://activemq.apache.org/static-transport-reference.html

　　　　所謂動態發現，就是部署前不需要知道所有AMQ實例的uri地址，只要進行相關配置，啓動後讓AMQ自己檢測。

　　　　需要修改AMQ配置文件，同時client端連接uri地址也要相應修改。

4、Network of Broker：

　　主要目的是實現負載均衡，提高消息處理能力。

　　一個client1連接broker1發送消息，另一個client2連接broker2消費消息，這時就需要將broker1上的消息路由到broker2上。而當broker2上的consumer掛了，也需要將消息轉發到其它的有consumer的broker上，避免消息大量堆積無法處理，目前的解決方案是Network of Broker。

　　官方資料：http://activemq.apache.org/networks-of-brokers.html

 

　　本文主要對ActiveMQ分佈式集羣相關知識進行整理總結，具體配置過程見上文中的官方資料，很詳細的。 

　　網上一些不錯的參考資料：

　　　　http://www.doc88.com/p-086413647667.html

　　　　http://wenku.baidu.com/view/d0cd7757ad02de80d4d8408a.html

　　　　http://bh-keven.iteye.com/blog/1617788