ActiveMQ的集羣方式主要由兩種：Master-Slave和Broker Cluster。
Master-Slave方式中，只能是Master提供服務，Slave是實時地備份Master的數據，以保證消息的可靠性。 當Master失效時，Slave會自動升級爲Master，客戶端會自動連接到Slave上工作。
Master-Slave模式分爲四類：
- Pure Master Slave
- Shared File System Master Slave
- JDBC Master Slave
- Replicated LevelDB Store
注意： Master-Slave方式都不支持負載均衡，但可以解決單點故障的問題，以保證消息服務的可靠性。
Pure Master Slave
ActiveMQ5.8以前支持，自從Activemq5.8開始，Activemq的集羣實現方式取消了傳統的Pure Master Slave方式，並從Activemq5.9增加了基於zookeeper+leveldb的實現方式。
使用兩個ActiveMQ服務器，一個作爲Master，Master不需要做特殊的配置；另一個作爲Slave，配置activemq.xml文件，在<broker>節點中添加連接到Master的URI和設置Master失效後不關閉Slave。
看到之前的ActiveMQ應該知道，這裏我們演示使用的ActiveMQ版本爲5.15.7（並且這都不是最新的），這裏我們就不演示該集羣方式的，感興趣的同學可以自己嘗試一下，其主要步驟就是上述說的，只需要Slave端的ActiveMQ的配置文件中進行配置忌口，可參考官網文檔http://activemq.apache.org/pure-master-slave.html
Shared File System Master Slave
利用共享文件系統做ActiveMQ集羣，是基於ActiveMQ的默認數據庫kahaDB完成的，kahaDB的底層是文件系統。這種方式的集羣，Slave的個數沒有限制，哪個ActiveMQ實例先獲取共享文件的鎖，那個實例就是Master，其它的ActiveMQ實例就是Slave，噹噹前的Master失效，其它的Slave就會去競爭共享文件鎖，誰競爭到了誰就是Master。這種模式的好處就是當Master失效時不用手動去配置，只要有足夠多的Slave。
但是該模式也存在一個缺點，就是我們不能夠把所有的ActiveMQ集羣部署在同一臺機器上呀，一般的話可能會在存在不同的機器上，那麼就需要用到分佈式文件系統了。
Shared JDBC Master Slave
JDBC Master Slave模式和Shared File Sysytem Master Slave模式的原理是一樣的，其中唯一不同的是，只是把共享文件系統換成了共享數據庫。我們只需在所有的ActiveMQ的主配置文件中activemq.xml添加數據源，所有的數據源都指向同一個數據庫，然後修改持久化適配器。
這種方式的集羣相對Shared File System Master Slave更加簡單，更加容易地進行分佈式部署，當然肯定也有是缺點的，如數據庫假如失效的話，那麼所有的ActiveMQ實例都將失效。
這裏我們就來測試一下，首先我們在本地準備三個ActiveMQ，然後因爲在本地進行集羣測試，所以我們需要修改其 conf 目錄下配置文件activemq.xml和jetty.xml中的端口號，主要是61616服務端口，以及8161控制檯頁面端口
上述我們分別改爲61616、61617、61618 和 8161、8162、8163 端口。
然後我們還需要爲每個ActiveMQ開啓網絡監控功能useJmx="true"，如下：
最後就需要就爲將每個ActiveMQ默認的存儲機制有KahaDB改爲數據庫存儲即可，這個我們在ActiveMQ存儲的持久化機制以及介紹過了，如下：
這樣就配置完成了，我們就可以依次啓動三個ActiveMQ服務了，服務啓動後，如下：
可以看到只有一臺MQ成爲Master，其餘兩臺成爲Slave並會嘗試成爲Master，並不斷重試。且兩臺Slave的管理控制檯將無法訪問。
然後我們在代碼中幾乎不用做太大的修改，只需修改其ActiveMQ的連接地址即可
在默認情況下，failover機制從URI列表中隨機選擇出一個URI進行連接，這可以有效地控制客戶端在多個broker上的負載均衡，但是要使客戶端首先連接到主節點，並在主節點不可用時只連接到輔助備份代理，需要設置randomize = false。
然後我們就可以啓動生產者和消費者了進行正常的通信了，當我們關閉一臺ActiveMQ服務，剩餘兩臺時，服務依舊可用，在關閉一臺，剩餘一臺ActiveMQ服務時，也是可以進行正常的通信的。
Replicated LevelDB Store
ActiveMQ5.9以後才新增的特性，使用ZooKeeper協調選擇一個node作爲master。被選擇的master broker node開啓並接受客戶端連接。 其他node轉入slave模式，連接master並同步他們的存儲狀態。slave不接受客戶端連接。所有的存儲操作都將被複制到連接至Master的slaves。
如果master死了，得到了最新更新的slave被允許成爲master。推薦運行至少3個replica nodes。
如上圖還必須要依賴於Zookeeper，用來以協調選擇一個服務作爲master，那麼爲什麼在Shared JDBC Master Slave中就不需要依賴於Zookeeper呢？原因在ActiveMQ存儲的持久化機制已經提過到了，在ActiveMQ使用數據庫作爲持久化機制時，在數據庫中會創建三種表，其中ACTIVEMQ_LOCK表就是用來確定集羣的Master Broker
這裏我們Replicated LevelDB Store採用的是ActiveMQ內置的LevelDB，LevelDB是一個Google實現的非常高效的kv數據庫，目前的版本1.2能夠支持billion級別的數據量了。 在這個數量級別下還有着非常高的性能，採用單進程的服務，性能非常之高，在一臺4核Q6600的CPU機器上，每秒鐘寫數據超過40w，而隨機讀的性能每秒鐘超過10w。
由此可以看出，具有很高的隨機寫，順序讀/寫性能，但是隨機讀的性能很一般，也就是說，LevelDB很適合應用在查詢較少，而寫很多的場景。LevelDB應用了LSM (Log Structured Merge) 策略，通過一種類似於歸併排序的方式高效地將更新遷移到磁盤，降低索引插入開銷。
從上述的描述看到LevelDB就非常適合ActiveMQ，因爲其寫入性能好就可以了，一般情況下ActiveMQ很少會進行讀取數據，其存儲的目的是持久化，一般都在內存中完成了，消息消費後會進行刪除，刪除也是一種寫入的行爲，只有很少的情況下，服務進行重啓，纔會進行讀取。
然後我們就來看看如何配置，其配置非常簡單，首先我們還是和上述一樣，在本地啓動三個ActiveMQ服務，並修改其端口號（上述已介紹），然後我們還需配置每個ActiveMQ的配置文件activemq.xml，幾乎都差不多，如下：
配置項說明：
- directory： 持久化數據存放地址
- replicas： 集羣中節點的個數
- bind： 集羣通信端口
- zkAddress： ZooKeeper集羣地址
- hostname： 當前服務器的IP地址，如果集羣啓動的時候報未知主機名錯誤，那麼就需要配置主機名到IP地址的映射關係。
- zkPath： ZooKeeper數據掛載點
然後我們先啓動Zookeeper服務，然後再依次啓動三個ActiveMQ服務，這裏只有當服務數過半集羣才能正常的運行，如下：
然後我們在啓動61617，集羣過半可以正常運行，發現61617被選舉爲Master節點
最後我們在啓動61618，肯定也是一個Slave節點，因爲Master已經被選舉出來了，這裏我們我們在啓動消息的生產者和消費者進行測試，代碼和之前一致，和上述一樣修改下連接地址即可，測試發現消息收發正常。
這裏我們將上述的61617 master服務關閉，發現61616被選舉爲master，然後再進行測試，發現集羣也是可以正常運行的。