ActiveMQ集羣總體認識

前言

最終須要掌握 Replicated LevelDB Store部署方式，這種部署方式是基於ZooKeeper的。

集羣分爲兩種方式：
1.僞集羣：集羣節點都搭在一臺機器上
2.真集羣：集羣節點分佈在多臺機器上
更多詳細： 真集羣與僞集羣的區別

1、爲何使用集羣？

1. 實現高可用，以排除單點故障引發的服務中斷。
2. 實現負載均衡，以提高效率爲更多的客戶提供服務。

2、ActiveMQ集羣部署方式

ActiveMQ集羣的部署方式主要有下面2種：

1. Broker Clusters 模式：實現負載均衡，多個broker之間同步消息，已達到服務器負載的可能。
2. Master Slave 模式：實現高可用，當主服務器宕機時，備用服務器能夠當即補充，以保證服務的繼續。

1. 失效轉移鏈接

該策略用於控制消費者的訪問，這是咱們在編寫代碼的時候要使用的鏈接方式。一個消費者鏈接到多個broker集羣的中的一個broker，當該broker出問題時，消費者自動鏈接到其餘一個正常的broker。消費者使用 failover 協議來鏈接broker，一般叫作 失效轉移（也叫故障轉移，斷線重連機制，FailOver）策略，語法以下：
failover:(uri1,uri2,...,uriN)?transportOptions

1.uri:消息服務器的地址 
2.transportOptions參數說明： 
        randomize：默認爲 true ，表示在URI列表中選擇URL鏈接時是否採用隨機策略。 
        initialReconnectDelay：默認爲10，單位爲毫秒，表示一次嘗試重連之間等待的時間。 
        maxReconnectDelay：默認 30000，單位毫秒，最長重連的時間間隔。

例如：

<!-- 
    1. client使用failover協議來與有效的master交互  
    2. master地址在前，slavew 在後，randomize 爲 false讓 Client優先與master通訊  
    3. 若是 master 失效，failover協議將會嘗試與slave創建連接，並依此重試
-->
failover:(tcp://localhost:61616,tcp://localhost:61617)?randomize=false

2. Broker Clusters 部署

Broker-Cluster的部署方式就能夠解決負載均衡的問題。Broker-Cluster部署方式中，各個broker經過網絡互相鏈接，並共享queue，保證消息同步。

各個broker進行消息同步使用的是NetworkConnection (網絡鏈接器)，主要用於配置各個broker之間的網絡通信方式，用於服務器傳遞信息。 分爲靜態鏈接器和動態鏈接器。

1. 靜態鏈接器

   <networkConnectors>
       <networkConnector uri="static:(tcp://127.0.0.1:61617,tcp://127.0.0.1:61618)"/> 
   </networkConnectors>

2. 動態鏈接器

   <!-- 網絡鏈接器 -->
   <networkConnectors>
       <networkConnector uri="multicast://default"/> 
   </networkConnectors>
   <!-- 傳輸鏈接器 -->
   <transprotConnectors>
       <transprotConnector uri="tcp://localhost:0" discoveryUri="multicast://default" />
   </transprotConnectors>

靜態鏈接器過於侷限，動態鏈接器可隨意擴展服務器鏈接。

3. Master Slave 部署（主從）

只須要掌握 Replicated LevelDB Store。

該 Master Slave主從方案所實現的 高可用架構具體內容可參考： ActiveMQ與HA架構(master/slave)

經過部署多個broker實例，選舉產生一個master和多個slave，master宕機後由slave接管服務來達到高可用性。Master-Slave的方式雖然能解決多服務熱備的高可用問題，但沒法解決負載均衡和分佈式的問題。Broker Cluster的部署方式恰好能夠解決負載均衡的問題。通常二者結合使用。
這裏主要介紹2種配置方案（通常只使用）：

1. Share storage master slave(共享存儲)
   包括：Shared File System Master slave 和 JDBC Store Master Slave 兩種模式
   此模式中Master和Slave的數據是共享的（至關於共享同一個數據庫），當master失效後，slave會自動接管服務，無需手動進行數據的copy與同步，由於master存儲數據以後，這些數據在任什麼時候候對slave都是可見的。
   master與slave之間，經過共享文件的「排他鎖」或者分佈式排他鎖(ZooKeeper)來決定Broker的狀態與角色，獲取鎖權限的Broker做爲master，其它的Broker則做爲slave。若是master失效，它必將失去鎖權限，那麼其它的slave將經過鎖競爭來選舉新master，沒有獲取鎖權限的Broker做爲slave，並等待鎖的釋放(間歇性嘗試獲取鎖)。

   • Shared File System Master Slave模式（只適合單臺主機部署，不適合多臺主機部署）

     這種方式是最經常使用的模式，架構簡單，可靠實用。咱們只須要一個SAN文件系統便可。使用文件系統來共享數據文件，多個Broker共享同一個文件系統。配置以下：
     ```
     <!-- 
     假設在本地啓動兩個broker,配置文件activemq.xml 裏面的持久化文件目錄都設置成同一個便可。  
     這裏默認使用的kahaDB ，你也能夠用levelDB，不推薦AMQDB  -->
     <persistenceAdapter>  
             <kahaDB directory="/opt/activemq/shared_kahadb" />  
     </persistenceAdapter>
     ```

   • JDBC Store Master Slave模式（適合多臺主機部署）

     數據存儲用的是數據庫（MySQL/Oracle等），相對於日誌文件而言，JDBC Store一般認爲是低效的。配置以下：
     ```
     <broker brokerName="broker-locahost-0">  
         <persistenceAdapter>  
             <jdbcPersistenceAdapter dataSource="#mysql-ds"/>  
         </persistenceAdapter>            
     </broker>  
      <!-- 配置jdbc數據庫鏈接 -->
     <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?relaxAutoCommit=true"/>  
         <property name="username" value="root"/>  
         <property name="password" value="root"/>  
         <property name="poolPreparedStatements" value="true"/>  
     </bean>  
     ```

2. Replicated LevelDB Store（使用ZooKeeper協調多個Broker）重要
   基於複製的LevelDB Store模式是ActiveMQ 5.9之後新增的特性，這是ActiveMQ全力打造的HA存儲引擎。 通常都使用這種方式。因爲利用zk 進行配置管理，能夠方便監控，同時配置也相對簡單。

   使用ZooKeeper（集羣）註冊全部的ActiveMQ Broker。只有其中的一個Broker能夠對外提供服務（也就是Master節點），其餘的Broker處於待機狀態，被視爲Slave。若是Master因故障而不能提供服務，則利用ZooKeeper的內部選舉機制會從Slave中選舉出一個Broker充當Master節點，繼續對外提供服務。

   因爲基於ZooKeeper（一般ZooKeeper集羣至少須要3個實例，才能保證ZooKeeper自己的高可用性），因此Broker最低須要3個。activemq.xml中配置以下：

   <!-- 持久化的部分爲ZooKeeper集羣鏈接地址-->  
   <persistenceAdapter>  
       <replicatedLevelDB  
         directory="${activemq.data}/leveldb"  
         replicas="3"  
         bind="tcp://0.0.0.0:0"  
         zkAddress="10.10.2.20:2181,10.10.2.21:2181,10.10.2.22:2181"  
         zkPassword="password"  
         zkPath="/opt/activemq/leveldb-stores"  
         hostname="10.10.2.20"  
         />  
   </persistenceAdapter>
   <!-- 
   # directory： 存儲數據的路徑
   # replicas：集羣中的節點數【(replicas/2)+1公式表示集羣中至少要正常運行的服務數量】，3臺集羣那麼容許1臺宕機， 另外兩臺要正常運行  
   # bind：當該節點成爲master後，它將綁定已配置的地址和端口來爲複製協議提供服務。還支持使用動態端口。只需使用tcp://0.0.0.0:0進行配置便可，默認端口爲61616。 
   # zkAddress：ZK的ip和port， 若是是集羣，則用逗號隔開(這裏做爲簡單示例ZooKeeper配置爲單點， 這樣已經適用於大多數環境了， 集羣也就多幾個配置) 
   # zkPassword：當鏈接到ZooKeeper服務器時用的密碼，沒有密碼則不配置。 
   # zkPah：ZK選舉信息交換的存貯路徑，啓動服務後actimvemq會到zookeeper上註冊生成此路徑   
   # hostname： ActiveMQ所在主機的IP
   # 更多參考：http://activemq.apache.org/replicated-leveldb-store.html
   -->

3、 Master Slave和Broker Cluster結合使用（經常使用方式）

---	高可用	負載均衡
Master Slave	是	否
Broker Cluster	否	是

Master Slave只能實現高可用性，不能實現負載均衡。
Broker Cluster 只能實現負載均衡，不能實現高可用性。
Master Slave和Broker Cluster 結合使用能夠實現高可用和負載均衡，以下圖：
按 A->B->C 順序啓動節點服務。

這個集羣是綜合了Broker Cluster和master/slave兩種基本集羣方式，其中master/slave（B和C）是基於共享存儲實現的。A和B組成消息同步，A和C組成消息同步是爲實現均衡負載，B和C組成master/slave是爲了實現高可用。

1. 若是A宕機，集羣退化成標準master/slave集羣，只是了失去負載均衡能力。
2. 若是B宕機，C會繼續提供服務，集羣退化成Broker Cluster集羣，失去高可用能力。
3. 若是C宕機也會失去高可用能力（同B）。

ABC不管哪一臺宕機，集羣都不會崩潰，可是須要迅速恢復。