一、activeMQ主要的幾類部署方式比較
1、預設的單機部署（kahadb）
activeMQ的預設儲存的單機方式，以本地kahadb檔案的方式儲存，所以效能指標完全依賴本地磁碟IO，不能提供高可用。
2、基於zookeeper的主從（levelDB Master/Slave）
5.9.0新推出的主從實現，基於zookeeper來選舉出一個master，其他節點自動作為slave實時同步訊息。
因為有實時同步資料的slave的存在，master不用擔心資料丟失，所以leveldb會優先採用記憶體儲存訊息，非同步同步到磁碟。所以該方式的activeMQ讀寫效能都最好，特別是寫效能能夠媲美非持久化訊息。
優點：
實現高可用和資料安全
效能較好
缺點：
因為選舉機制要超過半數，所以最少需要3臺節點，才能實現高可用。
可以基於postgres、mysql、oracle等常用資料庫。
每個節點啟動都會爭搶資料庫鎖，從而保證master的唯一性，其他節點作為備份，一直等待資料庫鎖的釋放。
因為所有訊息讀寫，其實都是資料庫操作，activeMQ節點本身壓力很小，效能完全取決於資料庫效能。
優點：
實現高可用和資料安全
簡單靈活，2臺節點就可以實現高可用
缺點：
穩定性依賴資料庫
效能依賴資料庫
二、效能測試：
用同一臺測試機作為master。測試程式碼為java，使用activemq-client-5.11.1提供的client，每個執行緒用一個連線反覆寫/讀，所有執行緒完畢後，彙總測試結果。
每秒寫/讀吞吐量測試結果如下（測試機效能較差，測試結果僅僅用來做3種部署方式的橫向比較）：
150/500表示每秒寫入150條，讀取500條訊息。
|
|
單執行緒 |
10執行緒
|
20執行緒 |
40執行緒
|
|
單機（kahadb）
|
150/500
|
350/2000
|
500/2000
|
480/2000
|
|
基於zk的主從（leveldb）
|
180/3000
|
600/5500
|
1400/6000
|
3200/4500
|
|
基於共享資料庫的主從
|
160/300
|
250/1050
|
250/1150
|
250/1200
|
三、災備方案（兩種方式都已經測試通過）
1、leveldb方式
需要3臺節點，2臺在主機房，1臺在備機房，主機房的節點權重設的比備機房節點高。
當master節點故障：
因為權重的關係，主機房另一個節點會自動被選舉為新的master。
當主機房故障：
需要啟動備用機房時，先更改備機房節點配置，把叢集規模從3改成1，這樣1個節點可以臨時提供服務（此時不再保證高可用）。
2、共享資料庫方式
3臺節點即可，2臺在主機房，1臺在備機房，備機房節點指向災備activeMQ資料庫，平時要關閉。
當master節點故障：
主機房的另一個節點會自動取得資料庫鎖，成為新的master。
當主機房故障：
需要啟動備用機房時，先完成activeMQ資料庫的切換，然後啟動災備activeMQ節點即可臨時外提供服務（此時不再保證高可用）。