activeMQ使用總結 (集羣方案)

1.   MQ現狀

1.1. 概述

ActiveMQ 是Apache出品，最流行的，能力強勁的開源消息總線。徹底支持JMS1.1和J2EE 1.4規範的JMS Provider實現

1.2. activemq的特性

• 多種語言和協議編寫客戶端。語言: Java, C, C++, C#, Ruby, Perl, Python, PHP。應用協議: OpenWire,Stomp REST,WS Notification,XMPP,AMQP
• 徹底支持JMS1.1和J2EE 1.4規範 (持久化,XA消息,事務)
• 對Spring的支持,ActiveMQ能夠很容易內嵌到使用Spring的系統裏面去,並且也支持Spring2.0的特性
• 經過了常見J2EE服務器(如 Geronimo,JBoss 4, GlassFish,WebLogic)的測試,其中經過JCA 1.5 resourceadaptors的配置,可讓ActiveMQ能夠自動的部署到任何兼容J2EE1.4商業服務器上
• 支持多種傳送協議:in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
• 支持經過JDBC和journal提供高速的消息持久化
• 從設計上保證了高性能的集羣,客戶端-服務器,點對點
• 支持Ajax
• 支持與Axis的整合
• 能夠很容易得調用內嵌JMS provider,進行測試

1.3. 現有方案

利用官方提供的基於network的cluster方案。

1.4. 存在問題

基於cluster的方案，用的版本比較舊5.6，其network之間通道存在tcp半鏈接問題，致使集羣頻頻出現問題。

目前是，直接採用一臺MQ進行業務操做，按現有業務，能夠支持現有的高併發。

實際上，目前迫切須要的是進行MQ的高可用，即Master-Slave方案

2.   MQ提供的集羣方案

2.1. broker-cluster負載方案

Broker-Cluster的部署方式就能夠解決負載均衡的問題。Broker-Cluster部署方式中，各個broker經過網絡互相鏈接，並共享queue。當broker-A上面指定的queue-A中接收到一個message處於pending狀態，而此時沒有consumer鏈接broker-A時。若是cluster中的broker-B上面由一個consumer在消費queue-A的消息，那麼broker-B會先經過內部網絡獲取到broker-A上面的message，並通知本身的consumer來消費。

2.1.1.   static Broker-Cluster部署

<networkConnectors> 

                <networkConnector   uri="static:(tcp:// 0.0.0.0:61617)"duplex="false"/>

</networkConnectors>

2.1.2.   Dynamic Broker-Cluster部署

<networkConnectors> 

           <networkConnectoruri="multicast://default"

           dynamicOnly="true"

           networkTTL="3"

           prefetchSize="1"

           decreaseNetworkConsumerPriority="true" />

</networkConnectors>

 

2.2. master-slave高可用方案

2.2.1.   shared filesystem Master-Slave部署方式

主要是經過共享存儲目錄來實現master和slave的熱備，全部的ActiveMQ應用都在不斷地獲取共享目錄的控制權，哪一個應用搶到了控制權，它就成爲master。

多個共享存儲目錄的應用，誰先啓動，誰就能夠最先取得共享目錄的控制權成爲master，其餘的應用就只能做爲slave。

 

2.2.2.   shared database Master-Slave方式

與shared filesystem方式相似，只是共享的存儲介質由文件系統改爲了數據庫而已。

2.2.3.   Replicated LevelDB Store方式

         這種主備方式是ActiveMQ5.9之後才新增的特性，使用ZooKeeper協調選擇一個node做爲master。被選擇的master broker node開啓並接受客戶端鏈接。

其餘node轉入slave模式，鏈接master並同步他們的存儲狀態。slave不接受客戶端鏈接。全部的存儲操做都將被複制到鏈接至Master的slaves。

若是master死了，獲得了最新更新的slave被容許成爲master。fialed node可以從新加入到網絡中並鏈接master進入slave mode。全部須要同步的disk的消息操做都將等待存儲狀態被複制到其餘法定節點的操做完成才能完成。因此，若是你配置了replicas=3，那麼法定大小是(3/2)+1=2. Master將會存儲並更新而後等待 (2-1)=1個slave存儲和更新完成，才彙報success。至於爲何是2-1，熟悉Zookeeper的應該知道，有一個node要做爲觀擦者存在。

單一個新的master被選中，你須要至少保障一個法定node在線以可以找到擁有最新狀態的node。這個node將會成爲新的master。所以，推薦運行至少3個replica nodes，以防止一個node失敗了，服務中斷。

2.3. 方案對比

• broker-cluster的集羣在多個broker之間fail-over和 load-balance
• master-slave能fail-over，可是不能load- balance
• 消息在多個broker之間轉發，可是消息只存儲在一個broker上，一旦失效必須重啓，而主從方式master失效，slave實時備份消息。
• jdbc方式成本高，效率低
• master-slave方式中pure方式管理起來麻煩

所以，咱們把MASTER/SLAVE和BROKER CLUSTER二者相結合，能夠獲得一個徹底解決方案：即又能夠作到集羣又能夠作到任何一個BROKER若是發生宕機節點消息也不丟失。

 

3.   最佳方案

3.1. 方案介紹

根據以上方案，結合優缺點，最終咱們須要實現集羣的高可用和負載均衡，因此結合後，基於zookeeper+network的集羣解決方案，具體以下圖所示：

 

集羣鏈接方式以下圖：

 

3.2. 升級策略

針對如今線上使用MQ的現狀分析，目前須要首先考慮支持高可用，因此以上方案可進行逐步實施：

1 對現有的MQ升級到最新版本，並測試驗證對5.6的兼容性

2 搭建基於zookeeper的Master-Slave集羣GA-MQ。

3 在高可用集羣GA-MQ和原有MQ之間創建network鏈接。

4 切換線上生產者到新的集羣GA-MQ

5 切換線上消費者到新的集羣GA-MQ

6 等待原有MQ消息徹底處理完成後，關閉服務。

7 搭建GB-MQ集羣，並按照業務進行負載劃分。

8 在GA-MQ和GB-MQ之間創建network鏈接，實現最終方案。

 

以上每一步，都須要進行嚴格的測試驗證，纔可進行生產環境的切換。