ActiveMQ實現簡單集羣和HA

先作一個簡單說明，我這個版本的ActiveMQ集羣部署並不嚴謹，對於大型企業可能並不適用，若有意見或者建議歡迎留言交流。

1. 集羣架構

** _一言不合就直接上架構圖 _ **

1. 集羣採用兩臺機器，四個實例部署，每臺機器上各部署兩個實例，一臺爲master，另外一臺爲slave。

2. HA實現：BrokerA和BrokerA-slave經過kahadb實現主備，哪一個先啓動，哪一個就是master，另一個就是slave；當master掛了，slave自動升級爲master，並對外提供服務。同理BrokerB和BrokerB-slave。
3. 集羣實現須要多個條件，如集羣是可負載均衡的、集羣間的主機是能夠相互通訊的、集羣中一臺主機掛了不會影響整個集羣對外提供服務。
   3.1. 實現條件一：client端必須經過failover訪問BrokerA和BrokerB。好比client發起100個請求，這100個請求會分攤在BrokerA和BrokerB上。
   3.2. 實現條件二：BrokerA須要經過網絡橋接聯通到BrokerB和BrokerB-slave，BrokerA-slave須要經過網絡橋接聯通BrokerB和BrokerB-slave。這樣，BrokerA收到消息後，能夠經過BrokerB去消費消息。BrokerB和BrokerB-slave同理。

如此，便基本實現了簡單的集羣和HA.

2. 集羣配置

2.1 IP及端口規劃

** 注**：admin端口爲後臺管理頁面的端口，配置在jetty.xml中。

2.2 activemq.xml及jetty.xml配置

** jetty.xml就涉及到後臺服務的端口修改，因此配置文件就很少作說明。**

• brokerA conf目錄下的activemq.xml配置修改

/修改brokerName/ <broker xmlns="http://activemq.apache.org/schema/core" brokerName="BrokerA" dataDirectory="${activemq.data}"> /修改kahaDB路徑/ <persistenceAdapter> <kahaDB directory="/home/dev/activeMQ/kahaDB"/> </persistenceAdapter> /修改網絡橋接/ <networkConnectors> <networkConnector uri="static:(tcp://host2:61616,tcp://host2:61617)" duplex="true"/> </networkConnectors>

- brokerA-slave conf目錄下的activemq.xml配置修改

    ```
/**修改brokerName**/
<broker xmlns="http://activemq.apache.org/schema/core" brokerName="BrokerA-slave" dataDirectory="${activemq.data}">
/**修改kahaDB路徑**/
<persistenceAdapter>
	<kahaDB directory="/home/dev/activeMQ/kahaDB"/>
</persistenceAdapter>
/**修改網絡橋接**/
<networkConnectors>
	<networkConnector uri="static:(tcp://host2:61616,tcp://host2:61617)" duplex="true"/>
</networkConnectors>

• brokerB conf目錄下的activemq.xml配置修改

/修改brokerName/ <broker xmlns="http://activemq.apache.org/schema/core" brokerName="BrokerB" dataDirectory="${activemq.data}"> /修改kahaDB路徑/ <persistenceAdapter> <kahaDB directory="/home/dev/activeMQ/kahaDB"/> </persistenceAdapter> /修改網絡橋接/ <networkConnectors> <networkConnector uri="static:(tcp://host1:61616,tcp://host1:61617)" duplex="true"/> </networkConnectors>

- brokerB-slave conf目錄下的activemq.xml配置修改

    ```
/**修改brokerName**/
<broker xmlns="http://activemq.apache.org/schema/core" brokerName="BrokerB-slave" dataDirectory="${activemq.data}">
/**修改kahaDB路徑**/
<persistenceAdapter>
	<kahaDB directory="/home/dev/activeMQ/kahaDB"/>
</persistenceAdapter>
/**修改網絡橋接**/
<networkConnectors>
	<networkConnector uri="static:(tcp://host1:61616,tcp://host1:61617)" duplex="true"/>
</networkConnectors>

3. 集羣測試

固然，集羣和HA要經得起考驗，經過如下幾個用例對其進行測試： ###3.1. 測試集羣負載 ####3.1.1. 用例一

• 前置條件：BrokerA和BrokerB做爲master對外提供服務
• 測試場景：producer經過failover向集羣發起10次請求(發送消息),看請求如何分配
• 過程分析：經過failover進行client負載，能夠將請求分攤到兩個實例上
• 測試結果：略

####3.1.2. 用例二

• 前置條件：BrokerA和BrokerB做爲master對外提供服務，兩個實例都有未消費的消息
• 測試場景：consumer經過failover向集羣發起消費消息請求，看請求如何分配
• 過程分析：經過failover進行client負載，能夠將請求分攤到兩個實例上
• 測試結果：略

###3.2. 測試集羣HA ####3.2.1. 用例一

• 前置條件：BrokerA和BrokerB做爲master對外提供服務
• 測試場景：將BrokerA kill掉，producer經過failover向集羣發送10次請求，看請求會如何分配
• 過程分析：BrokerA掛了後，釋放hakadb文件鎖，BrokerA-slave得到文件鎖，升級爲master並對外提供服務；經過failover進行client負載，能夠將請求分攤到兩個實例上
• 測試結果：請求會分攤到BrokerA-slave和BrokerB兩個實例上

####3.2.1. 用例二

• 前置條件：BrokerA和BrokerB做爲master對外提供服務，而且BrokerA上面有還未消費的消息
• 測試場景：將BrokerA kill掉，consumer經過failover向集羣發送消費消息請求
• 過程分析：BrokerA掛了後，未消費的消息持久化在hakadb中，BrokerA-slave升級爲master對外提供服務，並加載未消息的消息，因此consumer請求消費消息的時候能夠得到未消費的消息
• 測試結果：略

橋接方式的好處：

1. 當ActiveMQ面對大量消息存儲和大量Client交互時，性能消耗將會達到單個broker極限，此時咱們須要對ActiveMQ進行水平擴展。ActiveMQ提供了「network」機制，能夠把多個broker實例「串聯」一塊兒，造成「Forward Bridge」模型(轉發橋)。這些Broker經過有向網絡(networkerConnector)連接在一塊兒，組成broker集羣，任何一個Borker均可以與Client數據交互，消息也將在Broker網絡中「流動」直到被消費，之因此「流動」，由於「producer」和「consumer」會與不一樣的broker創建連接，咱們認爲「轉發橋」架構模式是「較大」集羣數據的解決方案。

2. 在master-slave模式中，消息將會在多個broker上備份，即集羣中每一個broker上消息都同樣，在故障轉移時不會發生消息丟失的問題(持久化消息)。「Forward Bridge」意味着消息能夠在broker間「轉發」直到消息被消費，在任意時刻一條消息只會被一個broker持有；Producer發送的消息，可能會通過多個Broker轉發最終纔會到達Consumer，若是其中某個Broker失效，那麼其上的消息將不可用（固然也能夠爲每一個節點採用M-S架構，以提升可用性），直到它再次加入集羣，所以「Forward Brige」模式並非ActiveMQ HA(高可用)方案,可是由於集羣中每一個Broker均可以獨立爲Client服務並且消息能夠動態的在網絡中遷移，因此「Forward Bridge」是解決海量消息的必備策略。

ref：

http://shift-alt-ctrl.iteye.com/blog/2070531