備忘用

訊息的儲存三種方式 ： kahaDB ,levelDB，資料庫。

（1） kahaDB 可以通過檔案共享來實現 高可用，需要對linux進行配置，這裡不做具體介紹。

（2）levelDB 是 activeMq 支援的一種高可用策略 ，需要搭建至少三個（奇數個）節點的zk叢集 ，我們的activeMq 也是需要三個。
（3）基於資料庫實現activeMq高可用 。

（4）通過負載可以實現“高可用”，缺陷是，掛掉的mq 中積壓的訊息，只能等他恢復，才能繼續消費（半可用）。

負載實現

靜態網路連線 & 動態網路連線 ：

兩個mq 的配置檔案中，分別配置靜態網路連線標籤，uri=static 分別指向對方的ip 。這樣他們之間可以互相消費，除此之外我們還需配置訊息迴流，這樣 brokerA 的消費者去消費 佇列 queueMsg時 ， brokerA 沒有回去brokerB要，當 brokerB 的消費者去消費 佇列 queueMsg 時，brokerB 會從 brokerA中要回來，就這樣互相來回消費。
弊端

<!--靜態網路連線-->   
<networkConnectors> 
         <networkConnector uri="static:(tcp://127.0.0.1:61617)"  />
</networkConnectors>

<!--動態網路連線,用的較少-->
<networkConnectors> 
         <networkConnector uri="multicast://default"
 
 name="bridge" dynamicOnly="false"                 conduitSubscriptions="true" decreaseNetworkConsumerPriority="false">
</networkConnectors>

配置好後， 我們在客戶端通過 ： failover 來進行對兩個 mq 的連線，randomize\=true 我們客戶端會隨機對brokerA,brokerB 進行連線，當 brokerA宕機了，他會將所有的連線都打在brokerB上 。 randomize\=false , 所有的客戶端連線都會打在第一個ip:port 上，只有第一個掛了，他才會打在第二個mq 上。

mq.property 檔案

mq.brokerURL=failover\:(tcp\://47.3.4.60\:61616,tcp\://47.13.12.16\:61616)?randomize\=true&initialReconnectDelay\=1000&maxReconnectDelay\=30000

spring-mq.xml 檔案

<bean id="targetConnectionFactory"class="org.apache.activemq.ActiveMQConnectionFactory">
        <!-- ActiveMQ服務地址 -->
        <property name="brokerURL" value="${mq.brokerURL}" />
        <property name="userName" value="${mq.userName}"></property>
        <property name="password" value="${mq.password}"></property>
</bean>

mysql 實現高可用

說明 ：客戶端連線同上 。

在兩個（以上）mq 的配置檔案中（activeMq.xml） 修改如下配置 ：

修改 persistenceAdapter
<persistenceAdapter>
        <!--kahadb 儲存-->
        <!--<kahaDB directory="${activemq.data}/kahadb_slavor"/>  -->
        <!--mysql 儲存-->
        <jdbcPersistenceAdapter  useDatabaseLock="true" dataSource="#mysql-ds"/>
</persistenceAdapter>   

<!--mysql 前 加 快取-->
<persistenceFactory>
 　　  　<journalPersistenceAdapterFactory  dataSource="#mysql_ds" dataDirectory="activemq-data"  />
</persistenceFactory>   

<!-- 資料庫連線配置 -->
<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/activemq-db?useUnicode=true"/>  
        <property name="username" value="root"/>  
        <property name="password" value="agui"/>  
        <property name="maxActive" value="200"/>  
        <property name="poolPreparedStatements" value="true"/>    
</bean> 

還需要引入三個jar 到 activemq 安裝的lib 目錄下，如圖 ：

啟動兩個（以上）mq , 會發現只有一個mq 成功啟動，另外一個處於等待鎖的狀態，這樣當 搶到鎖的mq 宕機了，其他的等待的mq 就繼續搶鎖，因為資料都在資料庫中，所有我們能保證所有的訊息都能完美消費。

弊端 : 吞吐效能完全依靠資料庫，效率低 。 即使加上了快取，可以提高速度，但是brokerA宕機了，他快取中的訊息還是無法寫入到資料庫，也無法給 新啟動的broker 去消費。

activemq-db資料庫表結構 ：

/*
Navicat MySQL Data Transfer

Source Server         : ceshi
Source Server Version : 50711
Source Host           : localhost:3306
Source Database       : activemq-db

Target Server Type    : MYSQL
Target Server Version : 50711
File Encoding         : 65001

Date: 2017-09-25 15:42:06
*/

SET FOREIGN_KEY_CHECKS=0;

-- ----------------------------
-- Table structure for activemq_acks
-- ----------------------------
DROP TABLE IF EXISTS `activemq_acks`;
CREATE TABLE `activemq_acks` (
  `CONTAINER` varchar(250) NOT NULL,
  `SUB_DEST` varchar(250) DEFAULT NULL,
  `CLIENT_ID` varchar(250) NOT NULL,
  `SUB_NAME` varchar(250) NOT NULL,
  `SELECTOR` varchar(250) DEFAULT NULL,
  `LAST_ACKED_ID` bigint(20) DEFAULT NULL,
  `PRIORITY` bigint(20) NOT NULL DEFAULT '5',
  `XID` varchar(250) DEFAULT NULL,
  PRIMARY KEY (`CONTAINER`,`CLIENT_ID`,`SUB_NAME`,`PRIORITY`),
  KEY `ACTIVEMQ_ACKS_XIDX` (`XID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

-- ----------------------------
-- Table structure for activemq_lock
-- ----------------------------
DROP TABLE IF EXISTS `activemq_lock`;
CREATE TABLE `activemq_lock` (
  `ID` bigint(20) NOT NULL,
  `TIME` bigint(20) DEFAULT NULL,
  `BROKER_NAME` varchar(250) DEFAULT NULL,
  PRIMARY KEY (`ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

-- ----------------------------
-- Table structure for activemq_msgs
-- ----------------------------
DROP TABLE IF EXISTS `activemq_msgs`;
CREATE TABLE `activemq_msgs` (
  `ID` bigint(20) NOT NULL,
  `CONTAINER` varchar(250) DEFAULT NULL,
  `MSGID_PROD` varchar(250) DEFAULT NULL,
  `MSGID_SEQ` bigint(20) DEFAULT NULL,
  `EXPIRATION` bigint(20) DEFAULT NULL,
  `MSG` longblob,
  `PRIORITY` bigint(20) DEFAULT NULL,
  `XID` varchar(250) DEFAULT NULL,
  PRIMARY KEY (`ID`),
  KEY `ACTIVEMQ_MSGS_MIDX` (`MSGID_PROD`,`MSGID_SEQ`),
  KEY `ACTIVEMQ_MSGS_CIDX` (`CONTAINER`),
  KEY `ACTIVEMQ_MSGS_EIDX` (`EXPIRATION`),
  KEY `ACTIVEMQ_MSGS_PIDX` (`PRIORITY`),
  KEY `ACTIVEMQ_MSGS_XIDX` (`XID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Zookeeper 實現 高可用

客戶端連線同上

說明 ：三個節點的zookeeper叢集部署在我的其他博文中已經介紹過了，這裡不再介紹。

缺點 ：
1) 佔用的節點數過多，1個zk叢集至少3個節點，1個activemq叢集也至少得3個節點，但其實正常執行時，只有一個master節點在對外響應，換句話說，花6個節點的成本只為了保證1個activemq master節點的高可用，太浪費資源了。

2) 效能下降太明顯，比起單節點的activemq，效能下降了近1個數量級。

修改三個mq 配置檔案 ：

 <persistenceAdapter>
         <!--<kahaDB directory="${activemq.data}/kahadb"/>-->
         <replicatedLevelDB
                 directory="activemq-data"
                 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"
                 zkPath="/activemq/leveldb-stores"
          />
</persistenceAdapter>

介紹 ：

directory : 儲存資料的路徑

replicas : 叢集中的節點數【(replicas/2)+1公式表示叢集中至少要正常執行的服務數量】， 3臺叢集那麼允許1臺宕機， 另外兩臺要正常執行

bind : 當這個節點成為Master， 它會繫結配置好的地址和埠來履行主從複製協議

zkAddress : ZooKeeper的ip和port， 如果是叢集， 則用逗號隔開(這裡作為簡單示例ZooKeeper配置為單點， 這樣已經適用於大多數環境了， 叢集也就多幾個配置)

zkPassword : 當連線到ZooKeeper伺服器時用的密碼

hostname : 本機ip

sync : 在認為訊息被消費完成前， 同步資訊所存貯的策略， 如果有多種策略用逗號隔開， ActiveMQ會選擇較強的策略（local_mem, local_disk則肯定選擇存貯在本地硬碟）

zkPath : ZooKeeper選舉資訊交換的存貯路徑

測試 ：

Step1 :

根據ZooKeeper的策略， 從三臺ActiveMQ伺服器選一臺執行， 其他兩臺等待執行， 只是做資料上的主從同步。

Step2 :

關閉能訪問http://ip:8161/admin/的ActiveMQ服務， 訪問其他兩個， 其中有一個能訪問， 說明ActiveMQ + ZooKeeper 叢集高可用配置已經成功。

注：為方便觀察輸出，建議啟動activemq時，用./activemq.sh console啟動

測試Failover

正常啟動後，然後手動停掉master，然後觀察剩下的2個節點終端輸出，正常情況下，應該過一會兒，有一個會自動提升為master.

最後提醒一下：採用上述HA(靜態迴流)方案後，雖然系統可用性提高了，但是在本機上測試發現，跟上篇同樣的測試程式碼和用例，單節點執行時，1秒可以發8k+條訊息，採用zookeeper的HA方案後，每秒只能寫入500條訊息左右，對於效能要求較高的場景，建議採用其它方案 。

優缺點對比

一、activeMQ主要的幾類部署方式比較
1、預設的單機部署（kahadb）
activeMQ的預設儲存的單機方式，以本地kahadb檔案的方式儲存，所以效能指標完全依賴本地磁碟IO，不能提供高可用。

2、基於zookeeper的主從（levelDB Master/Slave）
5.9.0新推出的主從實現，基於zookeeper來選舉出一個master，其他節點自動作為slave實時同步訊息。
因為有實時同步資料的slave的存在，master不用擔心資料丟失，所以leveldb會優先採用記憶體儲存訊息，非同步同步到磁碟。所以該方式的activeMQ讀寫效能都最好，特別是寫效能能夠媲美非持久化訊息。
優點：
實現高可用和資料安全
效能較好
缺點：
因為選舉機制要超過半數，所以最少需要3臺節點，才能實現高可用。

3、基於共享資料庫的主從（Shared JDBC Master/Slave）
可以基於postgres、mysql、oracle等常用資料庫。
每個節點啟動都會爭搶資料庫鎖，從而保證master的唯一性，其他節點作為備份，一直等待資料庫鎖的釋放。
因為所有訊息讀寫，其實都是資料庫操作，activeMQ節點本身壓力很小，效能完全取決於資料庫效能。
優點：
實現高可用和資料安全
簡單靈活，2臺節點就可以實現高可用
缺點：
穩定性依賴資料庫
效能依賴資料庫

二、效能測試：
用同一臺測試機作為master。測試程式碼為java，使用activemq-client-5.11.1提供的client，每個執行緒用一個連線反覆寫/讀，所有執行緒完畢後，彙總測試結果。
每秒寫/讀吞吐量測試結果如下（測試機效能較差，測試結果僅僅用來做3種部署方式的橫向比較）：
150/500表示每秒寫入150條，讀取500條訊息。

災備方案（兩種方式都已經測試通過）

1、leveldb方式
需要3臺節點，2臺在主機房，1臺在備機房，主機房的節點權重設的比備機房節點高。
當master節點故障：
因為權重的關係，主機房另一個節點會自動被選舉為新的master。
當主機房故障：
需要啟動備用機房時，先更改備機房節點配置，把叢集規模從3改成1，這樣1個節點可以臨時提供服務（此時不再保證高可用）。

2、共享資料庫方式
3臺節點即可，2臺在主機房，1臺在備機房，備機房節點指向災備activeMQ資料庫，平時要關閉。
當master節點故障：
主機房的另一個節點會自動取得資料庫鎖，成為新的master。
當主機房故障：
需要啟動備用機房時，先完成activeMQ資料庫的切換，然後啟動災備activeMQ節點即可臨時外提供服務（此時不再保證高可用）。

負載均衡 + 高可用 ：

其實上面三種 高可用策略（共享kahadb , leveldb ,sql） 加上我們的 靜態網路連線 + 迴流即可實現 ： 負載均衡 + 高可用。

值得說的是 ：

配置靜態網路連線的的時候比較麻煩，還容易亂。我們 兩個masterA,B， 每個master 各有一個slaveA,B。 我們不光需要在兩個 master 的配置檔案中配置彼此靜態網路連線，還得加上他們各自從的靜態網路連線對應的ip 。例如masterA和slaveA都要配置 masterB， slaveB 這兩個ip，如果 master水平擴充套件一個masterC，masterA和slaveA還要配置masterC，slaveC 的ip ， 其他 同理 。只有這樣叢集之間才能都互相監聽，即使某個節點掛了也不怕。

叢集 ： 負載均衡 + 高可用 ： 
通過配置靜態網路連線，來實現負載均衡， 高可用策略不變，唯一要說的是 ： 在高可用基礎上配置 networkconnector  uri=static:(tcp://1,2,3,4) 。
就是通過 各個 節點的mq (尤其是 cluster中 多個 主從架構中，主1的從 要靜態連線 主2和 主2下的從)，只有這樣才能保證 主2掛了， 主2下的從 頂替了主2 ， 主1獲取主1的從 還能從 新的 “主2”上要來資料。 

其他

（1）優化 ：
記憶體不足的時候，對接收端做限流 .
採用叢集。

（2）同步和非同步
Queue 同步 ： 當消費端沒有做出收到確認操作之前， 傳送端會堵塞當前程序， 等待消費端確認收到之後，開啟下一個程序。
非同步： 傳送端只管傳送，接收端只管接收。兩者互不影響。

（3）延遲消費注意事項 ：
為訊息加上延遲消費，還需要在 amq.xml 中加上這個配置即可，如下圖 ：

還是決定補充上 : kahadb 這種共享檔案，加鎖的方式，實現master-slave

比較簡單：單機部署兩個Amq , 直接修改各自的配置檔案 ：

<persistenceAdapter>
            <kahaDB directory="/home/simomme/mount/nas116/amq/kahadb"/>
</persistenceAdapter>

基於NFS搭建 檔案 的共享 ：

Linux下需要開啟NFS服務，具體操作如下：
建立共享目錄(192.168.0.1)：

1、 修改etc/exports，新增需要共享的目錄：/opt/mq/data *(rw,no_root_squash)
2、 啟動NFS服務 service nfs start/restart
3、 檢視共享 showmount –e
4、 NFS服務自啟動 chkconfig –level 35 nfs on

掛載共享目錄(192.168.0.2)：
1、 掛載：mount –t nfs 192.168.0.1:/opt/mq/data /opt/mq/data
2、 啟動自動掛載：在etc/fstab檔案新增10.175.40.244:/opt/mq/data /opt/mq/data nfs defaults 0 0
然後指定KahaDB的持久化目錄為/opt/mq/data即可。

<persistenceAdapter>
    <kahaDB directory="//ip/mqdata/kahadb"/>
</persistenceAdapter>