研究部朱懋柱
1.文檔介紹
1.1 文檔目的
對前期進(jìn)行的ActiveMQ研究進(jìn)行總結和分享ActiveMQ方面的心得。
1.2 文檔范圍
適合技術(shù)中心技術(shù)人員，可以作為技術(shù)參考。
1.3 參考文檔
ActiveMQ官方網(wǎng)站
http://activemq.apache.org/開(kāi)源中國社區
http://www.oschina.net/p/activemq百度百科
http://baike.baidu.com/view/157103.htm?fr=ala0_1_11.4 術(shù)語(yǔ)與縮寫(xiě)解釋
縮寫(xiě)、術(shù)語(yǔ) 解 釋
MQ 消息隊列，很多時(shí)候指消息中間件服務(wù)器
ActiveMQ ActiveMQ是一個(gè)開(kāi)放源碼基于A(yíng)pache 2.0 licenced 發(fā)布并實(shí)現了JMS 1.1的消息中間件
JMS jms即Java消息服務(wù)（Java Message Service）,一種協(xié)議標準
URI 資源標志符（Uniform Resource Identifier, 簡(jiǎn)稱(chēng)”URI”）
2. 研究背景介紹
為了快速有效的豐富匯訊的功能，減少開(kāi)發(fā)時(shí)間和開(kāi)發(fā)成本，我們將web的技術(shù)融合起來(lái)，技術(shù)融合中出現一個(gè)問(wèn)題就是消息實(shí)時(shí)通知匯訊客戶(hù)端的處理消息的流轉。簡(jiǎn)單的方法可以通過(guò)web服務(wù)器和IM服務(wù)器進(jìn)行直連來(lái)完成通信，但這樣的架構方案讓web和IM過(guò)于依賴(lài)，為了提供更好的擴展性，降低耦合，考慮引入消息中間件來(lái)作為兩者的中介，減少依賴(lài)，由此我們需要對消息中間件進(jìn)行一些分析和研究。
3. 技術(shù)說(shuō)明
ActiveMQ是一個(gè)開(kāi)放源碼基于A(yíng)pache 2.0 licenced 發(fā)布并實(shí)現了JMS 1.1的消息中間件，應用中引入中間件的好處是減少服務(wù)器之間的依賴(lài)關(guān)系，提高擴展性，在沒(méi)有引入消息中間件的情況可能出現如下圖所示：
出現服務(wù)器多依賴(lài)的情況，不方面擴展，而引入消息中間件后如
從圖中可以看出引入消息中間件后，每個(gè)服務(wù)器只依賴(lài)于消息中間件，而且在應用中這種依賴(lài)關(guān)系式一種弱依賴(lài)關(guān)系，為什么這么講呢？請看下節對消息中間件的分享報告。
4.ActiveMQ的技術(shù)分析
ActiveMQ實(shí)現了sub/pub（訂閱/發(fā)布）的機制，實(shí)現jms協(xié)議，sub/pub屬于設計模式中典型的觀(guān)察者模式，每臺服務(wù)器只需要訂閱自己希望得到的消息，而不必要輪詢(xún)服務(wù)器是否有自己需要的消息，也不需要知道消息發(fā)布者是誰(shuí)，而發(fā)布消息的一端也不需知道誰(shuí)是消息的接收端，有多少給接受者，這些都不重要，只要將消息發(fā)布到消息中間件就可以了。
ActiveMQ消息發(fā)布和訂閱的類(lèi)型分為BytesMessage(二進(jìn)制消息流的方式)、MapMessage（一種鍵值對方式的消息）、 ObjectMessage（一種序列化對象的消息形式）、TextMessage（字符流的消息類(lèi)型），可以根據需要進(jìn)行消息類(lèi)型選擇，當然對于同一個(gè)消息發(fā)布/訂閱雙方需要采用一致的消息類(lèi)型，同一個(gè)服務(wù)器可以采用多種消息格式，不過(guò)不同的消息格式需要獎勵不同的發(fā)布/和訂閱者。這樣一來(lái)應用就相當靈活，可以根據需要進(jìn)行類(lèi)型選擇，不過(guò)選擇ObjectMessage類(lèi)型的時(shí)候應該注意，這個(gè)消息類(lèi)型主要是序列化的Java對象，所以不支持不同的語(yǔ)言進(jìn)行類(lèi)型數據交換。
ActiveMQ應用程序接口(摘自百度百科)
ConnectionFactory 接口（連接工廠(chǎng)）
l 用戶(hù)用來(lái)創(chuàng )建到JMS提供者的連接的被管對象。JMS客戶(hù)通過(guò)可移植的接口訪(fǎng)問(wèn)連接，這樣當下層的實(shí)現改變時(shí)，代碼不需要進(jìn)行修改。 管理員在JNDI名字空間中配置連接工廠(chǎng)，這樣，JMS客戶(hù)才能夠查找到它們。根據消息類(lèi)型的不同，用戶(hù)將使用隊列連接工廠(chǎng)，或者主題連接工廠(chǎng)。
Connection 接口（連接）
l 連接代表了應用程序和消息服務(wù)器之間的通信鏈路。在獲得了連接工廠(chǎng)后，就可以創(chuàng )建一個(gè)與JMS提供者的連接。根據不同的連接類(lèi)型，連接允許用戶(hù)創(chuàng )建會(huì )話(huà)，以發(fā)送和接收隊列和主題到目標。
Destination 接口（目標）
l 目標是一個(gè)包裝了消息目標標識符的被管對象，消息目標是指消息發(fā)布和接收的地點(diǎn)，或者是隊列，或者是主題。JMS管理員創(chuàng )建這些對象，然后用戶(hù)通過(guò)JNDI發(fā)現它們。和連接工廠(chǎng)一樣，管理員可以創(chuàng )建兩種類(lèi)型的目標，點(diǎn)對點(diǎn)模型的隊列，以及發(fā)布者／訂閱者模型的主題。
MessageConsumer 接口（消息消費者）
l 由會(huì )話(huà)創(chuàng )建的對象，用于接收發(fā)送到目標的消息。消費者可以同步地（阻塞模式），或異步（非阻塞）接收隊列和主題類(lèi)型的消息。
MessageProducer 接口（消息生產(chǎn)者）
l 由會(huì )話(huà)創(chuàng )建的對象，用于發(fā)送消息到目標。用戶(hù)可以創(chuàng )建某個(gè)目標的發(fā)送者，也可以創(chuàng )建一個(gè)通用的發(fā)送者，在發(fā)送消息時(shí)指定目標。
Message 接口（消息）
l 是在消費者和生產(chǎn)者之間傳送的對象，也就是說(shuō)從一個(gè)應用程序創(chuàng )送到另一個(gè)應用程序。一個(gè)消息有三個(gè)主要部分：
l 消息頭（必須）：包含用于識別和為消息尋找路由的操作設置。
l 一組消息屬性（可選）：包含額外的屬性，支持其他提供者和用戶(hù)的兼容?？梢詣?chuàng )建定制的字段和過(guò)濾器（消息選擇器）。
l 一個(gè)消息體（可選）：允許用戶(hù)創(chuàng )建五種類(lèi)型的消息（文本消息，映射消息，字節消息，流消息和對象消息）。
l 消息接口非常靈活，并提供了許多方式來(lái)定制消息的內容。
Session 接口（會(huì )話(huà)）
l 表示一個(gè)單線(xiàn)程的上下文，用于發(fā)送和接收消息。由于會(huì )話(huà)是單線(xiàn)程的，所以消息是連續的，就是說(shuō)消息是按照發(fā)送的順序一個(gè)一個(gè)接收的。會(huì )話(huà)的好處是它支持事務(wù)。如果用戶(hù)選擇了事務(wù)支持，會(huì )話(huà)上下文將保存一組消息，直到事務(wù)被提交才發(fā)送這些消息。在提交事務(wù)之前，用戶(hù)可以使用回滾操作取消這些消息。一個(gè)會(huì )話(huà)允許用戶(hù)創(chuàng )建消息生產(chǎn)者來(lái)發(fā)送消息，創(chuàng )建消息消費者來(lái)接收消息。
MessageListener接口（消息監聽(tīng)者）
l 這是為一個(gè)消息消費者的消息監聽(tīng)接口，生產(chǎn)者必選設置消息監聽(tīng)者，否則消息將不處理，當客戶(hù)端接收到消息后，會(huì )通過(guò)調用消息監聽(tīng)者的接口來(lái)進(jìn)行相應的消息處理，一般在開(kāi)發(fā)過(guò)程中通過(guò)重載的方式重新定義監聽(tīng)著(zhù)的onMessage虛接口，來(lái)完成消息的監聽(tīng)和處理。
5．ActiveMQ的C++客戶(hù)端的實(shí)現
ActiveMQ提供了c++的client開(kāi)發(fā)庫支持，這樣我們實(shí)現起來(lái)就比較簡(jiǎn)單了，下面我們來(lái)看看發(fā)布和訂閱的簡(jiǎn)單例子。
5.1 pub（發(fā)布）端的簡(jiǎn)單實(shí)現過(guò)程
首先根據傳入的URI創(chuàng )建一個(gè)發(fā)布接口，創(chuàng )建過(guò)程如下：
然后調用發(fā)布接口發(fā)布消息，發(fā)布過(guò)程如下：
5.2 sub（訂閱）端的簡(jiǎn)單實(shí)現過(guò)程
訂閱者的創(chuàng )建過(guò)程和發(fā)布者的創(chuàng )建過(guò)程基本一樣，不過(guò)最后創(chuàng )建的不是生產(chǎn)者接口，而是消息消費者接口（MessageConsumer）,創(chuàng )建流程如下：
在實(shí)現時(shí)，我們重載消息消費者的監聽(tīng)者，并設置消息消費者的監聽(tīng)接口為我們實(shí)現的監聽(tīng)接口，再重載監聽(tīng)者onMessage接口來(lái)進(jìn)行消息處理。這樣，只要客戶(hù)端接收到消息，就會(huì )調用我們的監聽(tīng)者的onMessage接口，我們就可以在這個(gè)接口進(jìn)行相應的處理，完成消息接收處理過(guò)程。
5.3 消息處理過(guò)程
a) 消息訂閱
需要訂閱某主題的客戶(hù)端實(shí)現訂閱過(guò)程，產(chǎn)生消息消費者的監聽(tīng)者實(shí)例，并實(shí)現消息處理過(guò)程。
b) 消息發(fā)布
需要發(fā)布消息的客戶(hù)端實(shí)現消息發(fā)布的過(guò)程，等到一個(gè)生產(chǎn)者實(shí)力，并通過(guò)生產(chǎn)者接口向消息中間件發(fā)布消息。
c) 服務(wù)器消息轉發(fā)
消息中間件服務(wù)器收到生產(chǎn)者發(fā)送過(guò)來(lái)的消息后，查找是否有該類(lèi)型主題消息的訂閱者，有則分別發(fā)送消息。
d) 訂閱者消息處理
訂閱者客戶(hù)端收到消息中間件服務(wù)器發(fā)送過(guò)來(lái)的的消息后，調用監聽(tīng)者onMessage接口完成消息處理
6．總結
對ActiveMQ的研究尚淺，也許有些理解不當之處，歡迎大家指出，一起學(xué)習，消息中間件在跨語(yǔ)言和跨平臺，服務(wù)器間解耦都起到了比較到的作用。值得我們去學(xué)習，在此感謝所有提供免費網(wǎng)絡(luò )資源的網(wǎng)站，感謝開(kāi)源中國社區。
