activeMQ主要的幾類主從集羣部署方式

1、activeMQ主要的幾類部署方式比較

一、默認的單機部署（kahadb）

activeMQ的默認存儲的單機方式，以本地kahadb文件的方式存儲，因此性能指標徹底依賴本地磁盤IO，不能提供高可用。

 

二、基於zookeeper的主從（levelDB Master/Slave）

5.9.0新推出的主從實現，基於zookeeper來選舉出一個master，其餘節點自動做爲slave實時同步消息。

由於有實時同步數據的slave的存在，master不用擔憂數據丟失，因此leveldb會優先採用內存存儲消息，異步同步到磁盤。因此該方式的activeMQ讀寫性能都最好，特別是寫性能可以媲美非持久化消息。

優勢：

實現高可用和數據安全

性能較好

缺點：

由於選舉機制要超過半數，因此最少須要3臺節點，才能實現高可用。

 

三、基於共享數據庫的主從（Shared JDBC Master/Slave）

能夠基於postgres、mysql、oracle等經常使用數據庫。

每一個節點啓動都會爭搶數據庫鎖，從而保證master的惟一性，其餘節點做爲備份，一直等待數據庫鎖的釋放。

由於全部消息讀寫，其實都是數據庫操做，activeMQ節點自己壓力很小，性能徹底取決於數據庫性能。

優勢：

實現高可用和數據安全

簡單靈活，2臺節點就能夠實現高可用

缺點：

穩定性依賴數據庫

性能依賴數據庫

比較得知，採用基於zookeeper的主從（levelDB Master/Slave）模式

採用這種模式的關鍵配置地方在與每一個activemq.xml文件中下面位置：

下面的配置在三個實例上保持一致，除了標紅部分，主要修改配置文件conf/activemq.xml。 

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

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

把<persistenceAdapter>標籤中 kahaDB 改爲 LevelDB 方式，具體以下：

更改前：

更改後：

<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> 

注意：
replicas是主從服務器的總數量
hostname配置成當前服務器的物理ip便可。
zkAddress是所有zookeeper集羣的全部ip及端口。
bind是綁定本機網卡的物理ip，想省事就寫0.0.0.0 表示本機所有網卡

而後啓動三臺服務器activemq就能夠了.

以事務方式提交
Session session = connection.createSession(true, Session.SESSION_TRANSACTED);
生成完後最後再加上一句
session.commit();
測試效率每秒10000條左右，徹底知足設計要求。

本文出自http://blog.csdn.net/ziele_008/article/details/51883012