ActiveMQ基本介紹

一、ActiveMQ服務器工做模型

      經過ActiveMQ消息服務交換消息。消息生產者將消息發送至消息服務，消息消費者則從消息服務接收這些消息。這些消息傳送操做是使用一組實現 ActiveMQ應用編程接口 (API) 的對象來執行的。

      ActiveMQ客戶端使用 ConnectionFactory 對象建立一個鏈接，向消息服務發送消息以及從消息服務接收消息均是經過此鏈接來進行。Connection 是客戶端與消息服務的活動鏈接。建立鏈接時，將分配通訊資源以及驗證客戶端。這是一個至關重要的對象，大多數客戶端均使用一個鏈接來進行全部的消息傳送。  鏈接用於建立會話。Session 是一個用於生成和使用消息的單線程上下文。它用於建立發送的生產者和接收消息的消費者，併爲所發送的消息定義發送順序。會話經過大量確認選項或經過事務來支持可靠傳送。  客戶端使用 MessageProducer 向指定的物理目標（在 API 中表示爲目標身份對象）發送消息。生產者可指定一個默認傳送模式（持久性消息與非持久性消息）、優先級和有效期值，以控制生產者向物理目標發送的全部消息。 

一樣，客戶端使用 MessageConsumer 對象從指定的物理目標（在 API 中表示爲目標對象）接收消息。消費者可以使用消息選擇器，藉助它，消息服務能夠只向消費者發送與選擇標準匹配的那些消息。  消費者能夠支持同步或異步消息接收。異步使用可經過向消費者註冊 MessageListener 來實現。當會話線程調用 MessageListener 對象的 onMessage 方法時，客戶端將使用消息。

 

二、ActiveMQ消息傳送模型

ActiveMQ 支持兩種大相徑庭的消息傳送模型：PTP（即點對點模型）和Pub/Sub（即發佈 /訂閱模型），分別稱做：PTP Domain 和Pub/Sub Domain。 

 

PTP（使用Queue 即隊列目標） 消息從一個生產者傳送至一個消費者。在此傳送模型中，目標是一個隊列。消息首先被傳送至隊列目標，而後根據隊列傳送策略，從該隊列將消息傳送至向此隊列進行註冊的某一個消費者，一次只傳送一條消息。能夠向隊列目標發送消息的生產者的數量沒有限制，但每條消息只能發送至、並由一個消費者成功使用。若是沒有已經向隊列目標註冊的消費者，隊列將保留它收到的消息，並在某個消費者向該隊列進行註冊時將消息傳送給該消費者。 

 

Pub/Sub（使用 Topic即主題目標） 消息從一個生產者傳送至任意數量的消費者。在此傳送模型中，目標是一個主題。消息首先被傳送至主題目標，而後傳送至全部已訂閱此主題的活動消費者。能夠向主題目標發送消息的生產者的數量沒有限制，而且每一個消息能夠發送至任意數量的訂閱消費者。主題目標也支持持久訂閱的概念。持久訂閱表示消費者已向主題目標進行註冊，但在消息傳送時此消費者能夠處於非活動狀態。當此消費者再次處於活動狀態時，它將接收此信息。若是沒有已經向主題目標註冊的消費者，主題不保留其接收到的消息，除非有非活動消費者註冊了持久訂閱。

 

三、ActiveMQ消息選擇器

ActiveMQ提供了一種機制，使用它，消息服務可根據消息選擇器中的標準來執行消息過濾。生產者可在消息中放入應用程序特有的屬性，而消費者可以使用基於這些屬性的選擇標準來代表對消息是否感興趣。這就簡化了客戶端的工做，並避免了向不須要這些消息的消費者傳送消息的開銷。然而，它也使得處理選擇標準的消息服務增長了一些額外開銷。 消息選擇器是用於MessageConsumer的過濾器，能夠用來過濾傳入消息的屬性和消息頭部分（但不過濾消息體），並肯定是否將實際消費該消息。消息選擇器是一些字符串，它們基於某種語法，而這種語法是SQL-92的子集。能夠將消息選擇器做爲MessageConsumer 建立的一部分。

 

四、ActiveMQ消息簽收

在不帶事務的 Session 中，一條消息什麼時候和如何被簽收取決於Session的設置。 

1．Session.AUTO_ACKNOWLEDGE 

當客戶端從 receive 或 onMessage成功返回時，Session 自動簽收客戶端的這條消息的收條。在AUTO_ACKNOWLEDGE的 Session 中，同步接收 receive是上述三個階段的一個例外，在這種狀況下，收條和簽收緊隨在處理消息以後發生。 

2．Session.CLIENT_ACKNOWLEDGE 

    客戶端經過調用消息的 acknowledge 方法簽收消息。在這種狀況下，簽收發生在 Session 層面：簽收一個已消費的消息會自動地簽收這個 Session 全部已消費消息的收條。 

3．Session.DUPS_OK_ACKNOWLEDGE 

   此選項指示 Session 沒必要確保對傳送消息的簽收。它可能引發消息的重複，可是下降了 Session 的開銷，因此只有客戶端能容忍重複的消息，纔可以使用（若是ActiveMQ 再次傳送同一消息，那麼消息頭中的JMSRedelivered 將被設置爲 true）。客戶端成功接收一條消息的標誌是這條消息被簽收。成功接收一條消息通常包括以下三個階段： 

1．客戶端接收消息； 

2．客戶端處理消息； 

3．消息被簽收。簽收能夠由 ActiveMQ發起，也能夠由客戶端發起，取決於 Session 簽收模式的設置。 在帶事務的 Session 中，簽收自動發生在事務提交時。若是事務回滾，全部已經接收的消息將會被再次傳送。 

 

五、ActiveMQ消息傳送模式

ActiveMQ 支持兩種消息傳送模式：PERSISTENT 和 NON_PERSISTENT 兩種。 

1．PERSISTENT（持久性消息） 

        這是 ActiveMQ 的默認傳送模式，此模式保證這些消息只被傳送一次和成功使用一次。對於這些消息，可靠性是優先考慮的因素。可靠性的另外一個重要方面是確保持久性消息傳送至目標後，消息服務在向消費者傳送它們以前不會丟失這些消息。這意味着在持久性消息傳送至目標時，消息服務將其放入持久性數據存儲。若是消息服務因爲某種緣由致使失敗，它能夠恢復此消息並將此消息傳送至相應的消費者。雖然這樣增長了消息傳送的開銷，但卻增長了可靠性。 

2．NON_PERSISTENT（非持久性消息） 

    保證這些消息最多被傳送一次。對於這些消息，可靠性並不是主要的考慮因素。此模式並不要求持久性的數據存儲，也不保證消息服務因爲某種緣由致使失敗後消息不會丟失。 

有兩種方法指定傳送模式： 

1．使用 setDeliveryMode 方法，這樣全部的消息都採用此傳送模式； 

2．使用 send 方法爲每一條消息設置傳送模式。

 

六、ActiveMQ優先級設置

一般，能夠確保將單個會話向目標發送的全部消息按其發送順序傳送至消費者。然而，若是爲這些消息分配了不一樣的優先級，消息傳送系統將首先嚐試傳送優先級較高的消息。 

有兩種方法設置消息的優先級： 

1．使用 setDeliveryMode 方法，這樣全部的消息都採用此傳送模式； 

2．使用 send 方法爲每一條消息設置傳送模式； 

消息優先級從 0-9 十個級別，0-4 是普通消息，5-9 是加急消息。若是不指定優先級，則默認爲 4。JMS 不要求嚴格按照這十個優先級發送消息，但必須保證加急消息要先於普通消息到達。

 

七、ActiveMQ消息過時設置

容許消息過時 。默認狀況下，消息永不會過時。若是消息在特定週期內失去意義，那麼能夠設置過時時間。 

有兩種方法設置消息的過時時間，時間單位爲毫秒： 

1．使用 setTimeToLive 方法爲全部的消息設置過時時間； 

2．使用 send 方法爲每一條消息設置過時時間。

消息過時時間，send 方法中的 timeToLive 值加上發送時刻的 GMT 時間值。若是 timeToLive 值等於零，則 JMSExpiration 被設爲零， 表示該消息永不過時。若是發送後，在消息過時時間以後消息尚未被髮送到目的地，則該消息被清除。 

 

八、ActiveMQ持久訂閱設置

經過爲發佈者設置 PERSISTENT傳送模式，爲訂閱者時使用持久訂閱，這樣能夠保證 Pub/Sub 程序接收全部發布的消息。 

消息訂閱分爲非持久訂閱(non-durable subscription)和持久訂閱(durable subscription)，非持久訂閱只有當客戶端處於激活狀態，也就是和 ActiveMQ 保持鏈接狀態才能收到發送到某個主題的消息，而當客戶端處於離線狀態，這個時間段發到主題的消息將會丟失，永遠不會收到。持久訂閱時，客戶端向ActiveMQ 註冊一個識別本身身份的 ID，當這個客戶端處於離線時，ActiveMQ會爲這個 ID 保存全部發送到主題的消息，當客戶端再次鏈接到ActiveMQ 時， 會根據本身的 ID 獲得全部當本身處於離線時發送到主題的消息。持久訂閱會增長開銷，同一時間在持久訂閱中只有一個激活的用戶。 創建持久訂閱的步驟： 

1． 爲鏈接設置一個客戶 ID； 

2． 爲訂閱的主題指定一個訂閱名稱； 

上述組合必須惟一。 

 

 

九、ActiveMQ異步發送消息

ActiveMQ支持生產者以同步或異步模式發送消息。使用不一樣的模式對 send方法的 反應時間有巨大的影響，反映時間是衡量ActiveMQ 吞吐量的重要因素，使用異步發送

能夠提升系統的性能。 在默認大多數狀況下，AcitveMQ是以異步模式發送消息。例外的狀況：在沒有使用事務的狀況下，生產者以 PERSISTENT傳送模式發送消息。在這種狀況下，send方法都是同步的，而且一直阻塞直到 ActiveMQ發回確認消息：消息已經存儲在持久性數據存儲中。這種確認機制保證消息不會丟失，但會形成生產者阻塞從而影響反應時間。 

高性能的程序通常都能容忍在故障狀況下丟失少許數據。若是編寫這樣的程序，可以經過使用異步發送來提升吞吐量（甚至在使用PERSISTENT 傳送模式的狀況下）。

 

十、ActiveMQ消費者特性

（1）消費者異步分派 

在 ActiveMQ4 中，支持 ActiveMQ 以同步或異步模式向消費者分派消息。這樣的意義：能夠以異步模式向處理消息慢的消費者分配消息；以同步模式向處理消息快的消費

者分配消息。 ActiveMQ默認以同步模式分派消息（setDispatchAsync(false)或TEST.QUEUE?consumer.dispatchAsync=false），這樣的設置能夠提升性能。可是對於處理消息慢的消費者，須要以異步模式分派。 

 

（2）消費者優先級

在 ActveMQ 分佈式環境中，在有消費者存在的狀況下，若是更但願ActveMQ 發送消給消費者而不是其餘的 ActveMQ 到ActveMQ 的傳送，能夠以下設置： TEST.QUEUE?consumer.prority=10

 

（3）獨佔消費者

ActiveMQ維護隊列消息的順序並順序把消息分派給消費者。可是若是創建了多個Session 和 MessageConsumer，那麼同一時刻多個線程同時從一個隊列中接收消息時就並

不能保證處理時有序。 有時候有序處理消息是很是重要的。ActiveMQ4 支持獨佔的消費。ActiveMQ 挑選一個 MessageConsumer， 並把一個隊列中全部消息按順序分派給它。 若是消費者發生故障，那麼 ActiveMQ 將自動故障轉移並選擇另外一個消費者。能夠以下設置： TEST.QUEUE?consumer.exclusive=true

 

十一、ActiveMQ消息預取機制

ActiveMQ的目標之一就是高性能的數據傳送，因此 ActiveMQ 使用「預取限制」來 控制有多少消息能及時的傳送給任何地方的消費者。 一旦預取數量達到限制，那麼就不會有消息被分派給這個消費者直到它發回簽收消息（用來標識全部的消息已經被處理）。 能夠爲每一個消費者指定消息預取。若是有大量的消息而且但願更高的性能，那麼能夠爲這個消費者增大預取值。若是有少許的消息而且每條消息的處理都要花費很長的時間，那麼能夠設置預取值爲 1，這樣同一時間，ActiveMQ 只會爲這個消費者分派一條消息。如：TEST.QUEUE?consumer.prefetchSize=10