基於zookeeper+leveldb搭建activemq集羣

自從activemq5.9.0開始，activemq的集羣實現方式取消了傳統的Pure Master Slave方式，增長了基於zookeeper+leveldb的實現方式，其餘兩種方式：目錄共享和數據庫共享依然存在。 

本文主要闡述基於zookeeper和leveldb搭建activemq集羣，這裏須要特別提醒，本文實現的集羣僅提供主備功能，避免單點故障，沒有負載均衡功能。 

下面開始咱們的征途。 
1、搭建zookeeper集羣 

    關於搭建zookeeper集羣的文章請參考：Zookeeper 集羣搭建 

    本文使用zookeeper3.4.6，3臺虛擬機：192.168.2.161, 192.168.2.145, 192.168.2.146，zookeeper使用其默認端口：2181 

2、搭建activemq集羣 

一、安裝 
    activemq自己的安裝過程很簡單，本文不詳述，可參照官方的Getting-started 

二、配置 
    在三臺機器上完成activemq安裝以後，開始集羣配置，經過配置使三個activemq實例組成集羣。下面的配置在三個實例上保持一致，除了標紅部分，主要修改配置文件conf/activemq.xml。 

    （1）broker-name的統一 
        將broker標籤的brokerName屬性設置爲統一的值，我將這個值設置爲「test」，只有三個實例的brokerName一致，zookeeper才能識別它們屬於同一個集羣 

    （2）persistenceAdapter的配置 
        persistenceAdapter設置持久化方式，主要有三種方式：kahaDB（默認方式）、數據庫持久化、levelDB（v5.9.0提供支持） 
        本文采用levelDB來進行持久化，並使用zookeeper實現集羣的高可用，配置以下： 
        首先註釋掉原來kahaDB的持久化方式，而後配置levelDB+zookeeper的持久化方式。 

<broker brokerName="test" ... > 
... 
<!-- 
<persistenceAdapter> 
    <kahaDB directory="${activemq.data}/kahadb"/> 
</persistenceAdapter> 
--> 
<persistenceAdapter> 
    <replicatedLevelDB 
      directory="${activemq.data}/leveldb" 
      replicas="3" 
      bind="tcp://0.0.0.0:0" 
      zkAddress="192.168.2.161:2181,192.168.2.145:2181,192.168.2.146:2181" 
      hostname="192.168.2.161" 
      sync="local_disk" 
      zkPath="/activemq/leveldb-stores" 
      /> 
</persistenceAdapter> 
... 
</broker> 

    注意:上述配置中的hostname屬性值，不一樣的activemq實例對應不一樣的hostname值，其餘兩個實例配置的hostname值分別爲：192.168.2.145, 192.168.2.146 

3.如何工做 

  他使用Apach Zookeeper去協調集羣中的那個節點成爲master.被選擇爲master的節點開始工做並接收客戶端的鏈接。其餘的節點進入slave模式並鏈接到master同步他們的持久狀態。slave節點不接受客戶端的鏈接。全部持久操做被複制到鏈接的slave節點上。若是master節點死了，帶着最新更新數據的slave節點晉升爲master節點。失敗的節點而後可以回到在線而且他進入slave模式。 

  若是master死了，獲得了最新更新的slave被容許成爲master。fialed node可以從新加入到網絡中並鏈接master進入slave mode。全部須要同步到硬盤的消息的操做在他完成前將等待全部法定人數的節點複製完成。所以，若是你配置 replicas="3"，那麼法定人數的值是(3/2+1=2)。master節點在他報告成功以前將在本地存儲完最新的數據並等待1個其餘slave節點存儲完最新的數據。也就是，Master將會存儲並更新而後等待 (2-1)=1個slave存儲和更新完成，才彙報success。至於爲何是2-1，熟悉Zookeeper的應該知道，有一個node要做爲觀擦者存在。 

  當一個新的master節點要被選擇的時候，你也須要至少法定人數的節點在線爲可以找到一個帶着最新的更新數據的節點，那個帶着最新的更新數據的節點將變成新的master。所以，建議你至少運行3個重複節點以致你能down掉一個節點不影響服務的輸出。 


 


四、測試 

    測試目的：測試activemq的failover以及與zookeeper的整合 

    測試緣由：activemq有多種持久化模式，可是均可能存在單點故障的狀況。與zookeeper整合後基本能夠保證(n-1)/2的容錯率。其中n表示服務器數量 

    測試備註：該模式下仍是單節點負載，只是因爲引入了zookeeper的監測機制。保證多個activemq服務在同一時間內只有一個服務對外開放 

    而後就開始http://192.168.2.161:8161 或者http://192.168.2.145:8161 

或者http://192.168.2.146:8161 

    這三個連接看哪一個能訪問，哪一個消息服務器則表示存活提供服務 

    這種配置方案可以實現(n-1)/2的容錯率，也就是三臺服務器容許掛一臺，五個能當掉2個，依次類推 

    客戶端鏈接使用failover方案： 

failover:(tcp://192.168.1.191:61616,tcp://192.168.1.192:61616,tcp://192.168.1.193:61616)?initialReconnectDelay=1000 

    關掉其中任何一臺，通過測試可以正常提供服務，客戶端會自動切換鏈接，達到預期目的 

5.參考 

  http://activemq.apache.org/replicated-leveldb-store.html 

本文出自http://maosheng.iteye.com/blog/2224967