ActiveMQ的高級特性

1、消息的持久訂閱

在之前的pub/sub模式中，消費者只能消費自它訂閱之後的消息，這顯然是不合理的，有的應用場景就需要獲取之前的歷史信息。因此需要設置消息的持久化訂閱。

connection = factory.createConnection();
// 設置客戶端的唯一ID
connection.setClientID("AAA");

//destination = session.createTopic("HelloActiveMQ");
Topic topic = session.createTopic("HelloActiveMQ");
//consumer = session.createConsumer(destination);
consumer = session.createDurableSubscriber(topic,"AAA");

同時生產者發送消息的時候要進行持久化，默認是持久化消息。

即使Broker宕機，只要在宕機前將消息發送出去，服務啓動後，訂閱者也可以收到之前的消息。

消息自身持久化
訂閱者設置持久訂閱

2、消息的持久化機制

消息的持久化存儲也是保證可靠性的重要機制之一，消息發送到Broker上後，可以設置爲持久化方式，即使Broker宕機，恢復後也可以發送未處理的消息，默認是持久化的。

 producer.setDeliveryMode(DeliveryMode.PERSISTENT);

ActiveMQ支持多種不同的持久化方式：

KahaDB ，基於文件存儲
儲，默認的存儲方式
JDBC存儲
Memory存儲
LevelDB存儲
JDBC With Active MQ Journal

3、JMS的可靠性機制

相對於隊列的可靠性機制，生產者相對於隊列，消費者相對於隊列。

事務性會話
```
 session = connection.createSession(true,Session.AUTO_ACKNOWLEDGE);
```
生產者：消息發送完畢後，需要進行commit，否則發送不到隊列

消費者：消息收到後，也需要進行commit，否則隊列中的消息得不到消費
非事務性會話

 session = connection.createSession(false,Session.AUTO_ACKNOWLEDGE);

AUTO_ACKNOWLEDGE：自動確認

異步：當onMessage方法正常執行完畢，若該方法出現異常，隊列會進行重發，重發次數達到6次後消息進入死信隊列。所以一般使用try-catch-finally將業務代碼包起來。
同步：receive方法調用

CLIENT_ACKNOWLEDGE：需要手動確認，一次確認，可以確認之前的所有消息。

多個消費者消費同一批消息時，不確認的消息，會發給其它消費者。

DUPS_ACKNOWLEDGE：批量自動確認，但存在消息重複問題。

SESSION_TRANSACTED：事務提交，一次性可以單個和多個commit，或着rollback。

4、Request-Response模式

響應應答模式，JMS規範中並沒有直接提供這種模式，需要手動藉助消息頭定製協議。

藉助ReplyTo

生產者發送消息的時候，在消息頭中設置該消息的唯一ID，和消費者收到消息後要回應的destination，然後消費者就可以將響應消息發到該destination中，生產者監控這個destination，進而可以得到迴應消息。

唯一性ID可以區分消息，可能消費者對每一種消息的迴應都是不同的。這個ID一般放到緩存這種公共的地方，生產者消費者都可以看見。

5、死信隊列

用來保存處理失敗或者過期的消息，出現以下幾種情況，消息會被重發。

事務會話被回滾或者沒有commit
CLIENT_ACKNOWLEDGE情況下，沒有調用acknowledge方法，或者調用了recoover方法。
自動確認消息的方法中出現了異常

一個消息被重發六次以後，就會進入死信隊列，本質上還是一個普通的隊列，只是存儲已經過期的消息。

6、延遲隊列

修改配置文件，增加延遲和定時支持

<broker xmlns="http://activemq.apache.org/schema/core" brokerName="localhost" dataDirectory="${activemq.data}" schedulerSupport="true">

需要把幾個描述消息定時調度方式的參數作爲屬性添加到消息，broker端的調度器就會按照我們想要的行爲去處理消息。

一共有4個屬性

1：AMQ_SCHEDULED_DELAY ：延遲投遞的時間

2：AMQ_SCHEDULED_PERIOD ：重複投遞的時間間隔

3：AMQ_SCHEDULED_REPEAT：重複投遞次數

4：AMQ_SCHEDULED_CRON：Cron表達式

7、Master/Slave模式

Master-Slave方式中，只有Master提供服務，Slave是實時的備份Master的數據，保證消息的可靠性，當Master失效時，Slave會自動升級爲Master，客戶端會自動連接到Slave上工作。

架構圖

特點
- 只有Master對外提供服務
- 一個Master下面有一個或者多個Slaver
- 一個Slaver只能隸屬一個Master
- 整個主從架構只能有一個Mater
- 主從數據的複製是同步的
主從架構的實現方式
- 基於文件（Shared File Sysytem）

利用共享文件系統實現ActiveMQ集羣，基於默認的數據持久方式kahaDB完成，哪個節點先獲取到共享文件的鎖，哪個就是Master，其它的節點就是Slaver。

基於數據庫

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

然後修改持久化適配器。這種方式的集羣相對Shared File System Master Slave更加簡單，更加容易地進行分佈式部署，但是如果數據庫失效，那麼所有的ActiveMQ實例都將失效。

基於LevelDB，需要zookeeper的支持

利用zookeeper的master選舉機制，來實現ActiveMQ的主從模式。

8、ActiveMQ的集羣架構

採用水平擴展的方式，提供了HA的一種方案。

結構：

特點
- 失敗轉移：該環境下，每個JMS客戶端可能連接到任意一個broker節點，若該節點宕機則它會自動轉移的另一臺broker上，JMS客戶端連接到borker的連接方式爲failover://protocol
- 水平擴展：進行任意的水平擴展，添加broker即可
- 分佈式存儲：通過網絡將消息進行分佈式處理，將生產者對應的broker轉移到消費者對應的broker。
配置方式
- 靜態方式
- 動態方式

發表評論

所有評論

還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.

ActiveMQ的高級特性