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