ActiveMQ集羣應用

ActiveMQ集羣

        ActiveMQ具有強大和靈活的集羣功能,但在使用的過程中會發現很多的缺點,ActiveMQ的集羣方式主要由兩種:Master-Slave(ActiveMQ5.8版本已不可用)和Broker Cluster。

1、Master-Slave

        Master-Slave方式中,只能是Master提供服務,Slave是實時地備份Master的數據,以保證消息的可靠性。當Master失效 時,Slave會自動升級爲Master,客戶端會自動連接到Slave上工作。Master-Slave模式分爲三類:Pure Master Slave、Shared File System Master Slave和JDBC Master Slave。

(1)Pure Master Slave

    需要兩個Broker,一個作爲Master,另一個作爲Slave,運行時,Slave通過網絡實時從Master處複製數據,同時,如果Slave和Master失去連接,Slave就會自動升級爲Master,繼續爲客戶端提供消息服務,如圖所示:


   實踐時,我們使用兩個ActiveMQ服務器,一個作爲Master,Master不需要做特殊的配置;另一個作爲Slave,配 置${ACTIVEMQ_HOME}/conf/activemq.xml文件,在<broker>節點中添加連接到Master的URI和 設置Master失效後不關閉Slave,如下:

 

Xml代碼  
  1. <broker xmlns="http://activemq.apache.org/schema/core" brokerName="pure_slave" masterConnectorURI="tcp://0.0.0.0:61616" shutdownOnMasterFailure="false" dataDirectory="${activemq.base}">  

 

 同時修改Slave的服務端口,如:

 

Xml代碼  
  1. <transportConnectors>  
  2.             <transportConnector name="openwire" uri="tcp://0.0.0.0:61617"/>  
  3. </transportConnectors>  

 

爲了看到實踐的效果,Master和Slave的消息持久化介質都是採用MySQL,並且Master和Slave分別連接不同的數據庫。

    在消息生產者應用和消息消費者應用的Spring配置文件中添加以下紅色內容:

 客戶端連接消息中間服務器的url應修改爲“failover:(tcp://localhost:61616,tcp://localhost:61617)?initialReconnectDelay=100

 

    配置完成後,我們可以通過以下步驟來進行測試:

A、啓動 Master和Slave,啓動消息生產者應用,並分別發送一些Queue消息和Topic消息,如果此時訂閱Topic消息的消費者設置了 clientID,我們就可以在Master的數據庫和Slave的數據庫中看到尚未消費的消息,包括Queue和Topic的消息;

B、啓動消費者應用,可以接收到消息;

C、關閉消費者,生產者繼續發送一些消息A;

D、停止Master;

E、生產者繼續發送消息B;

F、啓動消費者應用,消費者可以接收到消息A和消息B,說明Slave接替了Master的工作並複製了Master的消息。

    這種方式只能兩臺機器做集羣,可以起到很好的雙機熱備功能,但只能失效一次,只能停機恢復Master-Slave結構。

 

 

(2)Shared File System Master Slave

        Shared File System Master Slave就是利用共享文件系統做ActiveMQ集羣,是基於ActiveMQ的默認數據庫kahaDB完成的,kahaDB的底層是文件系統。這種方式的集羣,Slave的個數沒有限制,哪個ActiveMQ實例先獲取共享文件的鎖,那個實例就是Master,其它的ActiveMQ實例就是Slave,噹噹前的Master失效,其它的Slave就會去競爭共享文件鎖,誰競爭到了誰就是Master。這種模式的好處就是當Master失效時不用手動去配置,只要有足夠多的SlaveShared File System Master Slave模式如圖所示:


  本例子是在一臺機器上運行三個ActiveMQ實例,需要對ActiveMQ的配置文件做一些簡單的配置,就是把持久化適配器的存儲目錄改爲本地磁盤的一個固定目錄,三個實例共享這個目錄,如下:

 

Xml代碼  
  1. <persistenceAdapter>  
  2.     <kahaDB directory="${activemq.data}/shared_file/data/kahadb" />  
  3. </persistenceAdapter> 

然後修改ActiveMQ實例的服務端口和jetty的服務端口,防止端口占用異常。啓動三個ActiveMQ實例,就可以進行測試了。

 

    以上配置只能在一臺機器進行,如果各個ActiveMQ實例需要運行在不同的機器,就需要用到分佈式文件系統了。

 

 

(3)JDBC Master Slave

        JDBC Master Slave模式和Shared File Sysytem Master Slave模式的原理是一樣的,只是把共享文件系統換成了共享數據庫。我們只需在所有的ActiveMQ的主配置文件中(${ACTIVEMQ_HOME}/conf/activemq.xml)添加數據源,所有的數據源都指向同一個數據庫,如:

 

Xml代碼  
  1. <bean id="mysql-ds" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">  
  2.         <property name="driverClassName" value="com.mysql.jdbc.Driver"/>  
  3.         <property name="url" value="jdbc:mysql://localhost:3306/cluster_jdbc?relaxAutoCommit=true"/>  
  4.         <property name="username" value="root"/>  
  5.         <property name="password" value="root"/>  
  6.         <property name="maxActive" value="200"/>  
  7.         <property name="poolPreparedStatements" value="true"/>  
  8. </bean>  

 

 

然後修改持久化適配器,修改配置文件的內容爲:

 

[plain] view plaincopy
 
  1. <persistenceAdapter>  
  2.             <!--<kahaDB directory="${activemq.data}/kahadb"/>-->  
  3.         <jdbcPersistenceAdapter dataDirectory="${activemq.data}" dataSource="#mysql-ds"/>  
  4. </persistenceAdapter>  



 

 

這種方式的集羣相對Shared File System Master Slave更加簡單,更加容易地進行分佈式部署,但是如果數據庫失效,那麼所有的ActiveMQ實例都將失效。

 

    以上三種方式的集羣都不支持負載均衡,但可以解決單點故障的問題,以保證消息服務的可靠性。

 

 

2、Broker Cluster

        Broker Cluster主要是通過network of Brokers在多個ActiveMQ實例之間進行消息的路由。Broker的集羣分爲Static DiscoveryDynamic Discovery兩種。

(1)Static Discovery集羣

Static Discovery集羣就是通過硬編碼的方式使用所有已知ActiveMQ實例節點的URI地址。如:消息生產者應用連接一個ActiveMQ實例,我們暫時稱爲MQ1,所有的消息都由該實例提供;兩個消息消費者應用分別連接另外兩個ActiveMQ實例,分別爲MQ2MQ3,兩個消息消費者需要消費MQ1上的消息,但它們連接的都不是MQ1,可以通過Static Discovery方式把MQ1上的消息路由到MQ2MQ3,爲了保證消費者不因某個節點的失效而導致不能消費消息,在消費者應用中需要配置所有節點的URI

生產者ActiveMQ實例不需要特殊的配置,所有的消費者ActiveMQ實例需要添加networkConnectors節點,連接到生產者MQ實例,如:

 

[plain] view plaincopy
 
  1. <networkConnectors>  
  2.             <networkConnector uri="static:(tcp://localhost:61616)" duplex="true"/>  
  3. </networkConnectors>  

Static Discovery集羣方式有些缺點,如不能解決單點故障問題,若某個Broker失效時,有可能造成數據的丟失,動態添加節點不夠智能化。

 

 

(2)Dynamic Discovery集羣

        Dynamic Discovery集羣方式在配置ActiveMQ實例時,不需要知道所有其它實例的URI地址,只需在所有實例的${ACTIVEMQ_HOME}/conf/activemq.xml文件中添加以下內容:

[plain] view plaincopy
 
  1. <networkConnectors>  
  2.           <networkConnector uri="multicast://default"/>  
  3. </networkConnectors>  

同時在<transportConnectors>節點中添加以下紅色部分內容:

 

[plain] view plaincopy
 
  1. <transportConnectors>  
  2.             <transportConnector name="openwire" uri="tcp://0.0.0.0:61616" <span style="color:#ff0000;">discoveryUri="multicast://default"</span> />  
  3.  </transportConnectors>  

 

 

這樣就可以實現消息在所有ActiveMQ實例之間進行路由。Dynamic Discovery集羣方式的缺點和Static Discovery一樣。

    從以上的分析可以看出,Master-Slave模式不支持負載均衡,但可以通過消息的實時備份或共享保證消息服務的可靠性,Broker Cluster模式支持負載均衡,可以提高消息的消費能力,但不能保證消息的可靠性。所以爲了支持負載均衡,同時又保證消息的可靠性,我們可以採用Msater-Slave+Broker Cluster的模式。



發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章