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

轉自：http://www.javashuo.com/article/p-yysvaehf-dt.html

ActiveMQ基本詳解與總結

基本使用能夠參考http://www.javashuo.com/article/p-qcswsdua-dh.html 和 https://blog.csdn.net/lifetragedy/article/details/51836557

• 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自己不提供管理工具；示例代碼少；主頁上的文檔看上去比較全面，可是缺少一種有效的組織方式，文檔只有片斷，用戶很難由淺入深進行了解，2、文檔總體的專業性太強。在研究階段能夠經過查maillist、看Javadoc、分析源代碼來了解。
• ActiveMQ應用場景：
  一、 不一樣語言應用集成
  ActiveMQ 中間件用Java語言編寫，所以天然提供Java客戶端 API。可是ActiveMQ 也爲C/C++、.NET、Perl、PHP、Python、Ruby 和一些其它語言提供客戶端。在你考慮如何集成不一樣平臺不一樣語言編寫應用的時候，ActiveMQ 擁有巨大優點。在這樣的例子中，多種客戶端API經過ActiveMQ 發送和接受消息成爲可能，不管使用的是什麼語言。此外，ActiveMQ 還提供交叉語言功能，該功能整合這種功能，無需使用遠程過程調用（RPC）確實是個優點，由於消息協助應用解耦。
  二、 做爲RPC的替代
  使用RPC同步調用的應用十分廣泛。假設大多數客戶端服務器應用使用RPC，包括ATM、大多數WEB應用、信用卡系統、銷售點系統等等。儘管不少系統很成功，可是轉換使用異步消息能夠帶來不少好處，並且也不會放棄響應保證。使用同步請求的系統在規模上有較大的限制，由於請求會被阻塞，從而致使整個系統變慢。若是使用異步消息替代，能夠很容易增長額外的消息接收者，使得消息能被併發消耗，從而加快請求處理。固然，你的系統應用間應該是解耦的。
  三、 應用之間解耦
  正如以前討論的，緊耦合架構能夠致使不少問題，尤爲是若是他們是分佈的。鬆耦合架構，在另外一方面，證明了更少的依賴性，可以更好地處理不可預見的改變。不只能夠在系統中改變組件而不影響整個系統，並且組件交互也至關的簡單。相比使用同步的系統（調用者必須等待被調用者返回信息），異步系統（調用方發送消息後就無論，即fire-and-forget）可以給咱們帶來事件驅動架構（event-driven architecture EDA）。
  四、 做爲事件驅動架構的主幹
  解耦，異步架構的系統容許經過代理器本身配置更多的客戶端，內存等（即vertical scalability）來擴大系統，而不是增長更多的代理器（即horizontal scalability）。考慮如亞馬遜這樣繁忙的電子商務系統。當用戶購買物品，事實上系統須要不少步驟去處理，包括下單，建立發票，付款，執行訂單，運輸等。可是用戶下單後，會當即返回「謝謝你下單」的界面。不僅是沒有延遲，並且用戶還會受到一封郵件代表訂單已經收到。在亞馬遜下單的例子就是一個多步處理的例子。每一步都由單獨的服務去處理。當用戶下單是，有一個同步的體積表單動做，但整個處理流程並不經過瀏覽器同步處理。相反地，訂單立刻被接受和反饋。而剩下的步驟就經過異步處理。若是在處理過程當中出錯，用戶會經過郵件收到通知。這樣的異步處理能提供高負載和高可用性。
  五、 提升系統擴展性
  不少使用事件驅動設計的系統是爲了得到高可擴展性，例如電子商務，政府，製造業，線上遊戲等。經過異步消息分開商業處理步驟給各個應用，可以帶來不少可能性。考慮設計一個應用來完成一項特殊的任務。這就是面向服務的架構（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。

AMQP的更多內容能夠看這裏： http://www.cnblogs.com/charlesblc/p/6058799.html

消息隊列-推/拉模式學習 & ActiveMQ及JMS學習

轉自：http://www.javashuo.com/article/p-bqvcyzyq-cr.html