天天看點

ActiveMQ小記(二):基于ZooKeeper的HA方案

從 ActiveMQ 5.9 開始,ActiveMQ 的叢集實作方式取消了傳統的Master-Slave 方式,增加了基于ZooKeeper + LevelDB的 Master-Slave實作方式,其他兩種方式目錄共享和資料庫共享依然存在。 

三種叢集方式的對比: 

(1)基于共享檔案系統(KahaDB,預設): 

<persistenceAdapter> 
	<kahaDB directory="${activemq.data}/kahadb"/> 
</persistenceAdapter>
           

(2)基于 JDBC:

<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/amq?relaxAutoCommit=true"/>
	<property name="username" value="root"/>
	<property name="password" value="root"/> <property name="maxActive" value="20"/>
	<property name="poolPreparedStatements" value="true"/>
</bean>
<persistenceAdapter>
	<jdbcPersistenceAdapter dataDirectory="${activemq.data}" dataSource="#mysql-ds" createTablesOnStartup="false"/>
</persistenceAdapter>
           

(3)基于可複制的 LevelDB(本文采用這種叢集方式): 

LevelDB 是 Google開發的一套用于持久化資料的高性能類庫。LevelDB并不是一種服務,使用者需要自 行實作Server。是單程序的服務,能夠處理十億級别規模Key-Value 型資料,占用記憶體小。 

<persistenceAdapter>
    <replicatedLevelDB
            directory="${activemq.data}/leveldb"
            replicas="3"
            bind="tcp://0.0.0.0:0"
            zkAddress="127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183"
            zkSessionTimeout="2s"
            hostname="lmg-zk-01"
            zkPath="/activemq/leveldb-stores"/>
</persistenceAdapter>
           

本文主要講解基于 ZooKeeper 和LevelDB 搭建ActiveMQ 叢集:

官方文檔:http://activemq.apache.org/replicated-leveldb-store.html 

ActiveMQ小記(二):基于ZooKeeper的HA方案

高可用的原理:使用ZooKeeper(叢集)注冊所有的ActiveMQ Broker。隻有其中的一個Broker 可以提供 服務,被視為Master,其他的Broker 處于待機狀态,被視為Slave。如果Master 因故障而不能提供服務,ZooKeeper 會從 Slave中選舉出一個 Broker充當 Master。 Slave 連接配接 Master并同步他們的存儲狀态,Slave不接受用戶端連接配接。所有的存儲操作都将被複制到連接配接至 Master 的Slaves。如果 Master 宕了,得到了最新更新的 Slave 會成為 Master。故障節點在恢複後會重新加入到叢集中并連接配接 Master 進入Slave 模式。 

解釋:需要同步的 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失敗了,服務中斷。(原理與 ZooKeeper 叢集的高可用實作方式類似)

一、activemq叢集配置

前提:環境的搭建,均一台機器上

準備好3份activemq可執行的檔案,

1)分别修改conf/activemq.xml,conf/jetty.xml檔案如下:

<persistenceAdapter>
    <replicatedLevelDB
            directory="${activemq.data}/leveldb"
            replicas="3"
            bind="tcp://0.0.0.0:0"
            zkAddress="127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183"
            zkSessionTimeout="2s"
            hostname="lmg-zk-01"
            zkPath="/activemq/leveldb-stores"/>
</persistenceAdapter>
           

為了避免沖突,確定端口和連接配接位址不一緻,如下設定:

uri port
activemq-1 tcp://0.0.0.0:51616 8161
activemq-2 tcp://0.0.0.0:51626 8162
activemq-3 tcp://0.0.0.0:51636 8163

注意:3個activemq節點中的`brokerName`必須相同,否則不能加入叢集

二、zookeeper叢集的搭建

可參考:http://www.cnblogs.com/yjmyzz/p/4587663.html

三、校驗

1)啟動zk1,zk2,zk3,以及activemq-1,activemq-2,activemq3

2)驗證

為了驗證是否高可用,我們采用Zooinspector對叢集節點狀态進行監控,Zooinspector的安裝見:https://github.com/liaomengge/zooinspector

分别開啟3個Zooinspector進行監控,其一圖如下:

ActiveMQ小記(二):基于ZooKeeper的HA方案

00000000004這個節點中的`elected`不為null,說明此節點為Master節點,然後,手動kill掉該Master節點,觀察Zooinspector的節點狀态,如下:

ActiveMQ小記(二):基于ZooKeeper的HA方案

00000000004被kill之後,00000000005提升為Master節點,繼續運作,即搭建成功。

參考文章:

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