3、ActiveMQ熱備方案

ActiveMQ熱備方案，主要保證ActiveMQ的高可用性。這種方案並不像上節中我們主要討論的ActiveMQ高效能方案那樣，同時有多個節點都處於工作狀態，也就是說這種方案並不提高ActiveMQ叢集的效能；而是從叢集中的多個節點選擇一個，讓其處於工作狀態，叢集中其它節點則處於待命狀態。當主要的工作節點由於各種異常情況停止服務時，保證處於待命的節點能夠無縫接替其工作。

3-1、ActiveMQ高效能方案的不足

那麼有的讀者可能會問，既然ActiveMQ的高效能方案中多個節點同時工作，在某個節點異常的情況下也不會影響其他節點的工作。這樣看來，ActiveMQ的高效能方案已經避免了單點故障，那麼我們為什麼還需要討論ActiveMQ的高可用方案呢？

為了回答這個問題，我們先回過頭來看看ActiveMQ高效能方案的一些不足。假設如下的場景：ActiveMQ A和AcitveMQ B兩個服務節點已建立了Network Bridge；並且Producer1 連線在ActiveMQ A上，按照一定週期傳送訊息（佇列名：Queue/testC）；但是當前並沒有任何消費者Consumer連線在任何ActiveMQ服務節點上接收訊息。整個場景如下圖所示：

在傳送了若干訊息後，我們檢視兩個節點ActiveMQ服務節點的訊息情況，發現ActiveMQ A並沒有把佇列Queue/testC中的訊息同步到ActiveMQ B。原來AcitveMQ Network Bridge的工作原則是：只在服務節點間傳輸需要傳輸的訊息

（ActiveMQ A節點中的Queue/testC佇列中有10條訊息）

（這些訊息並沒有被實時傳輸ActiveMQ B節點中，因為B節點中並沒有任何消費者監聽/訂閱這個佇列中的訊息）

那麼這樣的工作機制帶來的問題是，當沒有任何消費者在任何服務節點訂閱ActiveMQ A中佇列的訊息時，一旦ActiveMQ A由於各種異常退出，後來的消費者就再也收不到訊息，直到ActiveMQ A恢復工作

3-2、基於共享檔案系統的熱備方案

3-2-1、方案介紹

基於共享檔案系統的熱備方案可以說是ActiveMQ訊息中介軟體中最早出現的一種熱備方案。它的工作原理很簡單：讓若干個ActiveMQ服務節點，共享一個檔案系統。當某一個ActiveMQ服務搶佔到了這個檔案系統的操作許可權，就給檔案系統的操作區域加鎖；其它服務節點一旦發現這個檔案系統已經被加鎖（並且鎖不屬於本程序），就會自動進入Salve模式。

ActiveMQ早期的檔案儲存方案、KahaDB儲存方案、LevelDB儲存方案都支援這個工作模式。當某個ActiveMQ節點獲取了檔案系統的操作許可權後，首先做的事情就是從檔案系統中恢復記憶體索引結構：KahaDB恢復BTree結構；LevelDB恢復memTable結構。

因為本專題講解的技術體系都是工作在Linux作業系統上，所以為多個ActiveMQ提供共享檔案系統方案的第三方檔案系統都必須支援POSIX協議，這樣Linux作業系統才能實現遠端掛載。

幸運的是，這樣的第三方系統多不勝舉，例如：基於網路檔案儲存的NFS、NAS；基於物件儲存的分散式檔案系統Ceph、MFS、Swift（不是ios的程式語言）、GlusterFS（高版本）；以及ActiveMQ官方推薦的網路塊儲存方案：SAN（就是成本有點高）。

我會在我另外一個專題——“系統儲存”中，和大家深入討論這些儲存方案在效能、維護、擴充套件性、可用性上的不同。為了講解簡單，我們以下的講解採用NFS實現檔案系統的共享。NFS技術比較成熟，在很多業務領域都有使用案例。如果您的業務生產環境還沒有達到滴滴、大眾點評、美團那樣對檔案儲存效能上的要求，也可以將NFS用於生產環境。

3-2-2、例項參考

下面我們來演示兩個ActiveMQ節點建立在NFS網路檔案儲存上的 Master/Salve方案。關於怎麼安裝NFS軟體就不進行介紹了，畢竟本部分內容的核心還是訊息服務中介軟體，不清楚NFS安裝的讀者可以自行百度/Google。

以下是我們演示環境中的IP位置和功能：

關於NFS的安裝和使用我也會在另一個新的專題中進行介紹。

• 首先為兩個ActiveMQ節點掛載NFS服務

-- 在140上設定的NFS共享路徑為/usr/nfs 掛載到139和138的/mnt/mfdir/路徑下
-- 139和138上記得要安裝nfs-utils的客戶端模組
mount 192.168.61.140:/usr/nfs /mnt/mfdir/

• 1
• 2
• 3

掛在後，可以通過df命令查詢掛載在後的結果：

從上圖中可以看到，192.168.61.140上提供的NFS共享目錄通過mount命令掛載成為了138和139兩個物理機上的本地磁碟路徑。

• 然後更改138和139上ActiveMQ的主配置檔案，主要目的是將使用的KahaDB/LevelDB的主路徑設定為在共享檔案系統的相同位置：

......
<persistenceAdapter>
    <!--
    這裡使用KahaDB，工作路徑設定在共享路徑的kahaDB資料夾下
    138和139都設定為相同的工作路徑
    -->
    <kahaDB directory="/mnt/mfdir/kahaDB"/>
</persistenceAdapter>
......

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9

• 然後同時啟動138和139上的ActiveMQ服務節點。這時我們可以看到某個節點出現以下的提示資訊（記得是通過console模式進行觀察）：

......
jvm 1    |  INFO | Using Persistence Adapter: KahaDBPersistenceAdapter[/mnt/mfdir/kahaDB]
jvm 1    |  INFO | Database /mnt/mfdir/kahaDB/lock is locked by another server. This broker is now in slave mode waiting a lock to be acquired
......

• 1
• 2
• 3
• 4

在本文的演示環境中，出現以上提示的是工作在139上的ActiveMQ服務節點。這說明這個節點發現主工作路徑已經被其他ActiveMQ服務節點鎖定了，所以自動進入了Slave狀態。另外這還說明，另外執行在128物理機上的ActiveMQ服務搶佔到了主目錄的操作權。

接下來我們將工作在138上的ActiveMQ服務節點停止工作，這時139上的ActiveMQ Slave服務節點自動切換為Master狀態：

......
jvm 1    |  INFO | KahaDB is version 6
jvm 1    |  INFO | Recovering from the journal @1:47632
jvm 1    |  INFO | Recovery replayed 53 operations from the journal in 0.083 seconds.
jvm 1    |  INFO | PListStore:[/usr/apache-activemq-5.13.1/bin/linux-x86-64/../../data/activemq2/tmp_storage] started
jvm 1    |  INFO | Apache ActiveMQ 5.13.1 (activemq2, ID:vm2-46561-1461220298816-0:1) is starting
......

• 1
• 2
• 3
• 4
• 5
• 6
• 7

從以上的提示可以看到，139上的ActiveMQ節點在自己的記憶體區域恢復了KahaDB的索引資訊，並切換為Master狀態繼續工作。需要注意的是，在139上的ActiveMQ節點切換為Master狀態後，就算之前138上的ActiveMQ節點重新恢復工作，後者也不會再獲得主目錄的操作許可權，只能進入Salve狀態。

3-3、基於共享關係型資料庫的熱備方案

基於關係型資料庫的熱備方案它的工作原理實際上和基於共享檔案系統的熱備方案相似：

• 首先使用關係型資料庫作為ActiveMQ的持久化儲存方案時，在指定的資料庫中會有三張資料表：activemq_acks，activemq_lock，activemq_msgs（有的情況下您生成的資料表名會是大寫的，這是因為資料庫自身設定的原因）。

• 其中“activemq_lock”這張資料表記錄了當前對資料庫擁有操作許可權的ActiveMQ服務的ID資訊、Name資訊。各個ActiveMQ服務節點從這張資料表識別當前哪一個節點是Master狀態。

• 當需要搭建熱備方案時，兩個或者更多的ActiveMQ服務節點共享同一個資料服務。首先搶佔到資料庫服務的ActiveMQ節點，會將資料庫中“activemq_lock”資料表的Master狀態標記為自己，這樣其它ActiveMQ服務節點就會進入Salve狀態。

在我的之前的文章：《架構設計：系統間通訊（24）——提高ActiveMQ工作效能（下）》第7-5節已經向讀者講述瞭如何進行ActiveMQ服務的資料庫儲存方案的配置，這裡就不再進行贅述。只需要將每個ActiveMQ服務節點的資料庫連線設定成相同的位置，即可完成該熱備方案的配置工作。

為了便於各位讀者進行這種方案的配置實踐，這裡給出了關鍵的配置資訊：實際上真的很簡單，一定要首先確保您的資料庫是可用的，並且每一個ActiveMQ節點都這樣配置：

......
<broker xmlns="http://activemq.apache.org/schema/core">
    ......
    <persistenceAdapter>
        <!-- 設定使用的資料來源 -->
        <jdbcPersistenceAdapter dataSource="#mysql-ds"/>
    </persistenceAdapter>
    ......
</broker>
......

<!-- 一定要確保資料庫可用，且在ActiveMQ的lib目錄中有必要的jar檔案 -->
<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://您的mysql連線url資訊?relaxAutoCommit=true"/>
    <property name="username" value="activemq"/>
    <property name="password" value="activemq"/>
    <property name="poolPreparedStatements" value="true"/>
</bean>

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19

3-4、LevelDB + Zookeeper的熱備方案

從ActiveMQ V5.9.0+ 版本開始，ActiveMQ為使用者提供了一種新的Master/Salve熱備方案。這個方案中，我們可以讓每個節點都有自己獨立的LevelDB資料庫（不是像3-2小節那樣共享LevelDB的工作目錄），並且使用Zookeeper叢集控制多個ActiveMQ節點的工作狀態，完成Master/Salve狀態的切換。工作模式如下圖所示（摘自官網）：

在這種新的工作模式下，Master節點和各個Salve節點通過Zookeeper進行工作狀態同步，即使某個Salve節點新加入也沒有問題。下面我們一起來看看如何使用LevelDB + Zookeeper的熱備方案。下表中是我們將要使用的IP位置和相關位置的工作任務：

關於zookeeper，在我另外幾篇文章中有相關介紹（《hadoop系列：zookeeper（1）——zookeeper單點和叢集安裝》），在這裡的演示例項中我們使用單節點的ZK工作狀態（但是正式生產環境中，建議至少有三個zookeeper節點）。zookeeper的安裝過程就不在本小節中進行贅述了。

• 首先更改139和138上工作的ActiveMQ服務節點，讓它們使用獨立的LevelDB，並且都連線到zookeeper服務。

......
<!--
注意無論是master節點還是salve節點，它們的brokerName屬性都必須一致
否則activeMQ叢集就算連線到了zookeeper，也不會把他們當成一個Master/Salve組
-->
<broker xmlns="http://activemq.apache.org/schema/core"  brokerName="activemq" dataDirectory="${activemq.data}">
    ......
    <persistenceAdapter>
        <replicatedLevelDB
                directory="/usr/apache-activemq-5.13.1/data/levelDB"
                replicas="1"
                bind="tcp://0.0.0.0:61615"
                zkAddress="192.168.61.140:2181"
                zkPath="/activemq/leveldb"/>
    </persistenceAdapter>
    ......
</broker>
......

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18

我們介紹一下以上配置段落所使用的一些重要屬性。通過LevelDB + Zookeeper組建的熱備方案中肯定會有一個ActiveMQ節點充當Master節點，至於有多少個Salve節點就可以根據讀者所在團隊、專案、需求等因素來綜合考慮了。這些Master節點和Salve節點的主配置檔案中設定的brokerName屬性必須一致，否則activeMQ叢集就算連線到了zookeeper，也不會把他們當成一個Master/Salve組。

directory屬性是LevelDB的基本設定，表示當前該節點使用的LevelDB所在的主工作目錄，由於每個節點都有其獨立執行的LevelDB，所以各個節點的directory屬性設定的目錄路徑可以不一樣。但是根據對正式環境的管理經驗，建議還是將每個節點的directory屬性設定成相同的目錄路徑，方便進行管理。

對於replicas屬性，官方給出的解釋如下：

The number of nodes that will exist in the cluster. At least (replicas/2)+1 nodes must be online to avoid service outage.（default：3）

這裡的“number of nodes”包括了Master節點和Salve節點的總和。換句話說，如果您的叢集中一共有3個ActiveMQ節點，且只允許最多有一個節點出現故障。那麼這裡的值可以設定為2（當然設定為3也行，因為整型計算中 3 / 2 + 1 = 2）。但如果您將replicas屬性設定為4，就代表不允許3個節點的任何一個節點出錯，因為：(4 / 2) + 1 = 3，也就是說3個節點是本叢集能夠允許的最小節點數。

一旦zookeeper發現當前叢集中可工作的ActiveMQ節點數小於所謂的“At least (replicas/2)+1 nodes”，在ActiveMQ Master節點的日誌中就會給出提示：“Not enough cluster members connected to elect a master.”，然後整個叢集都會停止工作，直到有新的節點連入，並達到所規定的“At least (replicas/2)+1 nodes”數量。

bind屬性指明瞭當本節點成為一個Master節點後，通過哪一個通訊位置進行和其它Salve節點的訊息複製操作。注意這裡配置的監聽地址和埠不能在transportConnectors標籤中進行重複配置，否則節點在啟動時會報錯。

When this node becomes a master, it will bind the configured address and port to service the replication protocol. Using dynamic ports is also supported.

zkAddress屬性指明瞭連線的zookeeper服務節點所在的位置。在以上例項中由於我們只有一個zookeeper服務節點，所以只配置了一個位置。如果您有多個zookeeper服務節點，那麼請依次配置這些zookeeper服務節點的位置，並以“,”進行分隔：

zkAddress="zoo1.example.org:2181,zoo2.example.org:2181,zoo3.example.org:2181"

• 1

由於zookeeper服務使用樹形結構描述資料資訊，zkPath屬性就是設定整個ActiveMQ 主/備方案叢集在zookeeper儲存資料資訊的根路徑的位置。當然這個屬性有一個預設值“/default”，所以您也可以不進行設定。

• 在完成138和139兩個節點的ActiveMQ服務配置後，我們同時啟動這兩個節點（注意，為了觀察ActiveMQ的日誌請使用console模式啟動）。在其中一個節點上，可能會出現以下日誌資訊：

......
jvm 1    |  INFO | Opening socket connection to server 192.168.61.140/192.168.61.140:2181
jvm 1    |  INFO | Socket connection established to 192.168.61.140/192.168.61.140:2181, initiating session
jvm 1    |  INFO | Session establishment complete on server 192.168.61.140/192.168.61.140:2181, sessionid = 0x1543b74a86e0002, negotiated timeout = 4000
jvm 1    |  INFO | Not enough cluster members have reported their update positions yet.
jvm 1    |  INFO | Promoted to master
jvm 1    |  INFO | Using the pure java LevelDB implementation.
jvm 1    |  INFO | Apache ActiveMQ 5.13.1 (activemq, ID:vm2-45190-1461288559820-0:1) is starting
jvm 1    |  INFO | Master started: tcp://activemq2:61615
......

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10

從以上的日誌可以看到，這個節點連線上了zookeeper，並且分析了當前zookeeper上已連線的其它節點狀態後（實際上這個時候，還沒有其它節點進行連線），將自己“提升為Master”狀態。在另外一個AcitveMQ的節點日誌中，讀者可以發現另一種形式的日誌提示，類似如下：

......
jvm 1    |  INFO | Opening socket connection to server 192.168.61.140/192.168.61.140:2181
jvm 1    |  INFO | Socket connection established to 192.168.61.140/192.168.61.140:2181, initiating session
jvm 1    |  INFO | Session establishment complete on server 192.168.61.140/192.168.61.140:2181, sessionid = 0x1543b74a86e0005, negotiated timeout = 4000
jvm 1    |  INFO | Slave started
......

• 1
• 2
• 3
• 4
• 5
• 6

從日誌中可以看到，這個節點成為了一個Slave狀態的節點。

• 接下來我們嘗試停止當前Master節點的工作，並且觀察當前Salve節點的狀態變化。注意，如上文所述，replicas屬性的值一定要進行正確的設定：如果當Master節點停止後，當前還處於活動狀態的節點總和小於“(replicas/2)+1”，那麼整個叢集都會停止工作！

......
jvm 1    |  INFO | Not enough cluster members have reported their update positio ns yet.
jvm 1    |  INFO | Slave stopped
jvm 1    |  INFO | Not enough cluster members have reported their update positio ns yet.
jvm 1    |  INFO | Promoted to master
jvm 1    |  INFO | Using the pure java LevelDB implementation.
jvm 1    | Replaying recovery log: 5.364780% done (956,822/17,835,250 bytes) @ 1 03,128.23 kb/s, 0 secs remaining.
jvm 1    | Replaying recovery log: 9.159451% done (1,633,611/17,835,250 bytes) @  655.68 kb/s, 24 secs remaining.
jvm 1    | Replaying recovery log: 23.544615% done (4,199,241/17,835,250 bytes)  @ 2,257.21 kb/s, 6 secs remaining.
jvm 1    | Replaying recovery log: 89.545681% done (15,970,696/17,835,250 bytes)  @ 11,484.08 kb/s, 0 secs remaining.
jvm 1    | Replaying recovery log: 100% done
jvm 1    |  INFO | Master started: tcp://activemq1:61615
......

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13

從以上的日誌片段可以看到，Salve節點接替了之前Master節點的工作狀態，並恢復之前已同步的LevelDB檔案到本節點的本地記憶體中，繼續進行工作。

我們在這篇文章做的演示只有兩個ActiveMQ服務節點和一個Zookeeper服務節點，主要是為了向讀者介紹ActiveMQ下 LevelDB + Zookeeper的高可用方案的配置和切換過程，說明ActiveMQ高可用方案的重要性。實際生產環境下，這樣的節點數量配置會顯得很單薄，特別是zookeeper服務節點只有一個的情況下是不能保證整個叢集穩定工作的。正式環境下， 建議至少使用三個zookeeper服務節點和三個ActiveMQ服務節點，並將replicas屬性設定為2。

3-5、ActiveMQ客戶端的故障轉移

以上三種熱備方案，都已向各位讀者介紹。細心的讀者會發現一個問題，因為我們沒有使用類似Keepalived那樣的第三方軟體支援浮動IP。那麼無論以上三種熱備方案的哪一種，雖然服務端可以無縫切換提供連續的服務，但是對於客戶端來說連線伺服器的IP都會發生變化。也就是說客戶端都會因為連線異常脫離正常工作狀態。

為了解決這個問題，AcitveMQ的客戶端連線提供了配套的解決辦法：連線故障轉移。開發人員可以預先設定多個可能進行連線的IP位置（這些位置不一定同時都是可用的），ActiveMQ的客戶端會從這些連線位置選擇其中一個進行連線，當連線失敗時自動切換到另一個位置連線。使用方式類似如下：

......
//這樣的設定，即使在傳送/接收訊息的過程中出現問題，客戶端連線也會進行自動切換
ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory("failover:(tcp://192.168.61.138:61616,tcp://192.168.61.139:61616)");
......

• 1
• 2
• 3
• 4

這樣的連線設定下，客戶端的連線就可以隨服務端活動節點的切換完成相應的轉換。

4、形成生產環境方案

ActiveMQ中主要的高效能、高可用方案到此就為各位讀者介紹完了。可以看到在ActiveMQ單個節點效能配置已優化的前提下，ActiveMQ叢集的高效能方案可能會出現節點失效訊息服務停止的情況（請參見3-1小節所述）；而ActiveMQ叢集的高可用性方案中，由於一次只有一個節點是Master狀態可以提供訊息服務外，其他Salve節點都不能提供服務，所以並不能提高整個ActiveMQ叢集的效能。

因為兩種方案都有其限制因素，所以在實際工作中將ActiveMQ應用到生產環境時，除非您的業務環境有特殊要求的情況，一般建議將ActiveMQ的高效能方案和高可用方案進行結合。以下向各位讀者提供一種ActiveMQ高效能和高可用性結合的方案：

• 將9個ActiveMQ節點分為三組（brokerName1、brokerName2、brokerName3），每組都有三個ActiveMQ服務節點。另外準備三個節點的zookeeper服務叢集，所有三個組九個ActiveMQ服務都共享這三個zookeeper服務節點（只是每組ActiveMQ所設定的zkPath屬性不一樣）

• 將每組的三個ActiveMQ服務節點做LevelDB + Zookeeper的熱備方案（且設定replicas=2）。保證每組只有一個節點在一個時間內為Master狀態。這樣整個叢集中的九個ActiveMQ服務節點就同時會有三個ActiveMQ服務節點處於Master狀態。

• 將整個叢集中所有ActiveMQ服務節點的高效能方案設定為“組播發現”，並都採用一個相同的組播地址（可以採用預設的組播地址）。這樣三個處於Master狀態的ActiveMQ服務節點就會形成一個高效能方案（處於Salve狀態的節點不會發出組播訊息）。整個設計結構如下圖所示：

5、下文介紹

下文我們將介紹出ActiveMQ訊息中介軟體以外的，業界流行的其它中介軟體產品（包括RabbitMQ、Kafka和ZeroMQ）。由於篇幅的問題，這些中介軟體產品我們只做概要新介紹（本來原計劃是要詳細介紹RabbitMQ的，只有以後有時間再補上咯）。之後，我將和讀者一起討論如何基於中介軟體技術解決生產過程中遇到的實際問題。整個訊息佇列的知識介紹就暫告一段落。