1. 程式人生 > >ActiveMQ基本詳解與總結& 訊息佇列-推/拉模式學習 & ActiveMQ及JMS學習

ActiveMQ基本詳解與總結& 訊息佇列-推/拉模式學習 & ActiveMQ及JMS學習

ActiveMQ基本詳解與總結

  • MQ簡介:
      MQ全稱為Message Queue, 訊息佇列(MQ)是一種應用程式對應用程式的通訊方法。應用程式通過寫和檢索出入列隊的針對應用程式的資料(訊息)來通訊,而無需專用連線來連結它們。訊息傳遞指的是程式之間通過在訊息中傳送資料進行通訊,而不是通過直接呼叫彼此來通訊,直接呼叫通常是用於諸如遠端過程呼叫的技術。排隊指的是應用程式通過佇列來通訊。佇列的使用除去了接收和傳送應用程式同時執行的要求。其中較為成熟的MQ產品有IBMWEBSPHERE MQ。
  • MQ特點:
      MQ的消費-生產者模型的一個典型的代表,一端往訊息佇列中不斷的寫入訊息,而另一端則可以讀取或者訂閱佇列中的訊息。MQ和JMS類似,但不同的是JMS是SUN JAVA訊息中介軟體服務的一個標準和API定義,而MQ則是遵循了AMQP協議的具體實現和產品。
  • 使用場景:
      在專案中,將一些無需即時返回且耗時的操作提取出來,進行了非同步處理,而這種非同步處理的方式大大的節省了伺服器的請求響應時間,從而提高了系統的吞吐量。
  • JMS簡介:
      JMS即Java訊息服務(Java Message Service)應用程式介面是一個Java平臺中關於面向訊息中介軟體(MOM)的API,用於在兩個應用程式之間,或分散式系統中傳送訊息,進行非同步通訊。Java訊息服務是一個與具體平臺無關的API,絕大多數MOM提供商都對JMS提供支援。
  • 定義:
      JMS(Java Messaging Service)是Java平臺上有關面向訊息中介軟體(MOM)的技術規範,它便於訊息系統中的Java應用程式進行訊息交換,並且通過提供標準的產生、傳送、接收訊息的介面簡化企業應用的開發,翻譯為Java訊息服務。
  • 簡介:
      JMS是一種與廠商無關的 API,用來訪問訊息收發系統訊息。它類似於JDBC(Java DatabaseConnectivity):這裡,JDBC 是可以用來訪問許多不同關係資料庫的 API,而 JMS 則提供同樣與廠商無關的訪問方法,以訪問訊息收發服務。許多廠商目前都支援JMS,包括 IBM 的 MQSeries、BEA的 Weblogic JMS service和 Progress 的 SonicMQ,這只是幾個例子。 JMS 使您能夠通過訊息收發服務(有時稱為訊息中介程式或路由器)從一個 JMS 客戶機向另一個JMS客戶機發送訊息。訊息是 JMS 中的一種型別物件,由兩部分組成:報頭和訊息主體。報頭由路由資訊以及有關該訊息的元資料組成。訊息主體則攜帶著應用程式的資料或有效負載。根據有效負載的型別來劃分,可以將訊息分為幾種型別,它們分別攜帶:簡單文字(TextMessage)、可序列化的物件 (ObjectMessage)、屬性集合 (MapMessage)、位元組流 (BytesMessage)、原始值流 (StreamMessage),還有無有效負載的訊息 (Message)。
  • JMS和MQ的關係:
      JMS是一個用於提供訊息服務的技術規範,它制定了在整個訊息服務提供過程中的所有資料結構和互動流程。而MQ則是訊息佇列服務,是面向訊息中介軟體(MOM)的最終實現,是真正的服務提供者;MQ的實現可以基於JMS,也可以基於其他規範或標準。
    支援JMS的開源MQ:
    目前選擇的最多的是ActiveMQ。
  • ActiveMQ 是Apache出品,最流行的,能力強勁的開源訊息匯流排。ActiveMQ 是一個完全支援JMS1.1和J2EE 1.4規範的 JMS Provider實現,儘管JMS規範出臺已經是很久的事情了,但是JMS在當今的J2EE應用中間仍然扮演著特殊的地位。
    主要特點:
    1. 多種語言和協議編寫客戶端。語言: Java, C, C++, C#, Ruby, Perl, Python, PHP。應用協議: OpenWire,Stomp REST,WSNotification,XMPP,AMQP
    2. 完全支援JMS1.1和J2EE 1.4規範 (持久化,XA訊息,事務)
    3. 對Spring的支援,ActiveMQ可以很容易內嵌到使用Spring的系統裡面去,而且也支援Spring2.0的特性
    4. 通過了常見J2EE伺服器(如 Geronimo,JBoss 4, GlassFish,WebLogic)的測試,其中通過JCA 1.5 resource adaptors的配置,可以讓ActiveMQ可以自動的部署到任何相容J2EE 1.4 商業伺服器上
    5. 支援多種傳送協議:in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
    6. 支援通過JDBC和journal提供高速的訊息持久化
    7. 從設計上保證了高效能的叢集,客戶端-伺服器,點對點
    8. 支援Ajax
    9. 支援與Axis的整合
    10. 可以很容易得呼叫內嵌JMS provider,進行測試
    11. ActiveMQ速度非常快;一般要比jbossMQ快10倍。
  • 優點:
      是一個快速的開源訊息元件(框架),支援叢集,同等網路,自動檢測,TCP,SSL,廣播,持久化,XA,和J2EE1.4容器無縫結合,並且支援輕量級容器和大多數跨語言客戶端上的Java虛擬機器。訊息非同步接受,減少軟體多系統整合的耦合度。訊息可靠接收,確保訊息在中介軟體可靠儲存,多個訊息也可以組成原子事務。
  • 缺點:
      ActiveMQ預設的配置效能偏低,需要優化配置,但是配置檔案複雜,ActiveMQ本身不提供管理工具;示例程式碼少;主頁上的文件看上去比較全面,但是缺乏一種有效的組織方式,文件只有片段,使用者很難由淺入深進行了解,二、文件整體的專業性太強。在研究階段可以通過查maillist、看Javadoc、分析原始碼來了解。
  • ActiveMQ應用場景:
    1、 不同語言應用整合
    ActiveMQ 中介軟體用Java語言編寫,因此自然提供Java客戶端 API。但是ActiveMQ 也為C/C++、.NET、Perl、PHP、Python、Ruby 和一些其它語言提供客戶端。在你考慮如何整合不同平臺不同語言編寫應用的時候,ActiveMQ 擁有巨大優勢。在這樣的例子中,多種客戶端API通過ActiveMQ 傳送和接受訊息成為可能,無論使用的是什麼語言。此外,ActiveMQ 還提供交叉語言功能,該功能整合這種功能,無需使用遠端過程呼叫(RPC)確實是個優勢,因為訊息協助應用解耦。
    2、 作為RPC的替代
    使用RPC同步呼叫的應用十分普遍。假設大多數客戶端伺服器應用使用RPC,包括ATM、大多數WEB應用、信用卡系統、銷售點系統等等。儘管很多系統很成功,但是轉換使用非同步訊息可以帶來很多好處,而且也不會放棄響應保證。使用同步請求的系統在規模上有較大的限制,因為請求會被阻塞,從而導致整個系統變慢。如果使用非同步訊息替代,可以很容易增加額外的訊息接收者,使得訊息能被併發消耗,從而加快請求處理。當然,你的系統應用間應該是解耦的。
    3、 應用之間解耦
    正如之前討論的,緊耦合架構可以導致很多問題,尤其是如果他們是分佈的。鬆耦合架構,在另一方面,證實了更少的依賴性,能夠更好地處理不可預見的改變。不僅可以在系統中改變元件而不影響整個系統,而且元件互動也相當的簡單。相比使用同步的系統(呼叫者必須等待被呼叫者返回資訊),非同步系統(呼叫方傳送訊息後就不管,即fire-and-forget)能夠給我們帶來事件驅動架構(event-driven architecture EDA)。
    4、 作為事件驅動架構的主幹
    解耦,非同步架構的系統允許通過代理器自己配置更多的客戶端,記憶體等(即vertical scalability)來擴大系統,而不是增加更多的代理器(即horizontal scalability)。考慮如亞馬遜這樣繁忙的電子商務系統。當用戶購買物品,事實上系統需要很多步驟去處理,包括下單,建立發票,付款,執行訂單,運輸等。但是使用者下單後,會立即返回“謝謝你下單”的介面。不只是沒有延遲,而且使用者還會受到一封郵件表明訂單已經收到。在亞馬遜下單的例子就是一個多步處理的例子。每一步都由單獨的服務去處理。當用戶下單是,有一個同步的體積表單動作,但整個處理流程並不通過瀏覽器同步處理。相反地,訂單馬上被接受和反饋。而剩下的步驟就通過非同步處理。如果在處理過程中出錯,使用者會通過郵件收到通知。這樣的非同步處理能提供高負載和高可用性。
    5、 提高系統擴充套件性
    很多使用事件驅動設計的系統是為了獲得高可擴充套件性,例如電子商務,政府,製造業,線上遊戲等。通過非同步訊息分開商業處理步驟給各個應用,能夠帶來很多可能性。考慮設計一個應用來完成一項特殊的任務。這就是面向服務的架構(service-oriented architecture SOA)。每一個服務完成一個功能並且只有一個功能。應用就通過服務組合起來,服務間使用非同步訊息和最終一致性。這樣的設計便可以引入一個複雜事件處理概念(complex event processing CEP)。使用CEP,部件間的互動可以被記錄追蹤。在非同步訊息系統中,可以很容易在部件間增加一層處理。
      
  • 個人理解總結:
    activeMQ是什麼?
      是Apache公司旗下的一個訊息匯流排
    ActiveMQ是一個開源相容Java Message Service (JMS) 1.1面向訊息的中件間. 來自Apache Software Foundation. ActiveMQ提供鬆耦合的應用程式架構.
    activeMQ能幹什麼?
      用來在服務與服務之間進行非同步通訊的
  • activeMQ優勢
    1.流量肖鋒
    2.任務非同步處理
    特點:可以解耦合
      (學習新技術的三要素:是什麼?能幹什麼?有什麼優勢?)

     圖1:
    這裡寫圖片描述

  • 通訊模式:
    1.點對點(queue)
    》一個訊息只能被一個服務接收
    》訊息一旦被消費,就會消失
    》如果沒有被消費,就會一直等待,直到被消費
    》多個服務監聽同一個消費空間,先到先得
    詳解:這個特點的原理是這樣的,在activeMQ

  • 2.釋出/訂閱模式(topic)
      》一個訊息可以被多個服務接收
      》訂閱一個主題的消費者,只能消費自它訂閱之後釋出的訊息。
      》消費端如果在生產端傳送訊息之後啟動,是接收不到訊息的,除非生產端對訊息進行了持久化(例如廣播,只有當時聽到的人能聽到資訊)

      圖2:
     這裡寫圖片描述 

注:訊息是被推送和拉取的(訊息生產端和消費端),不是mq伺服器去主動傳送的
- 總:一些簡單常用的應用場景
1.傳送郵件
詳解:
  最經典的就是當用戶註冊時,我們就需要用activeMQ來做為中介軟體,當用戶註冊後,我門把使用者的郵箱號和驗證碼等資訊通過activeMQ的生產端傳送到activeMQ的訊息佇列中,而一旦訊息佇列中出現了資料,我們的郵件模組通過實時的監控activeMQ的訊息佇列就能通過消費端獲取到這個資料,染回郵件模組就會自行的去對資料進行解析,給使用者傳送郵件
2.傳送簡訊
詳解:
  原理同傳送郵件相同
3.同步索引庫
詳解:
  為了緩解資料庫的壓力,我們把經常被呼叫的資料放入索引庫中,當有請求查詢時,我們會先去查詢索引庫,如果索引庫內有資料,那麼我們就不用就資料庫進行查詢,這樣就能大大的減輕伺服器的壓力,可是隨之而來的一個問題是,假如我們伺服器內的資料已經發生了改變,而瀏覽使用者查詢資料時,因為索引庫中已經有資料了,那麼這樣一來資料庫與索引庫的資料就不一致了,那麼怎麼解決這個問題呢?我們想到了通過用activeMQ來監聽資料庫的操作來實現資料庫與索引庫的資料同步,當後臺管理員或房產經紀人對資料庫的資料進行了增刪改的操作時,我們通過activeMQ監聽到了資料的改變,獲取到被修改的資料的id,然後在另一個服務模組中通過這個資料的id去資料庫先查詢一把,然後根據查詢結果進行判斷,再去做索引庫的資料同步。打個比方,如果查詢結果返回的是空,就說明商品已經被刪除,那麼我們就可以根據資料的id去把索引庫中的資料也一併刪除了。
4.同步靜態頁面
詳解:
  此原理同上一個同步索引庫是一個原理,目的都是為了減緩伺服器的壓力,我們經過資料分析發現,其實我們的一些商品詳情頁面的資料其實都是大同小異的,完全可以通過freemarker頁面靜態化的模組加上後臺查詢出的資料拼裝成一個靜態頁面,而這些資料從哪來呢?我們經過討論和研究,最後一致認為還是放在緩衝中比較好,這樣一來就能大大的減輕了資料 庫的壓力,而另一個好處是,由於頁面是純靜態頁面,所以頁面上的資料都是死資料,這樣一來就不用像JSP動態頁面那樣需要和後臺資料庫有大量的資料互動,可以最大化的降低伺服器的壓力,其實這個技術已經有很多大型公司在使用了,比如淘寶,京東,網易等,我們要是細心一些就會發現,他們的頁面其實就都是HTML格式的靜態頁面。

訊息中介軟體的主要功能是訊息的路由(Routing)和快取(Buffering)。在AMQP中提供類似功能的兩種域模型:Exchange 和 Message queue。

訊息佇列-推/拉模式學習 & ActiveMQ及JMS學習