MQ簡介：

MQ全稱為Message Queue, 消息隊列（MQ）是一種應用程序對應用程序的通信方法胚鸯。應用程序通過寫和檢索出入列隊的針對應用程序的數(shù)據(jù)（消息）來通信，而無需專用連接來鏈接它們返帕。消息傳遞指的是程序之間通過在消息中發(fā)送數(shù)據(jù)進行通信委煤，而不是通過直接調用彼此來通信，直接調用通常是用于諸如遠程過程調用的技術溜歪。排隊指的是應用程序通過隊列來通信抄肖。隊列的使用除去了接收和發(fā)送應用程序同時執(zhí)行的要求久信。其中較為成熟的MQ產品有IBMWEBSPHERE MQ。

MQ特點：

MQ的消費-生產者模型的一個典型的代表漓摩，一端往消息隊列中不斷的寫入消息裙士，而另一端則可以讀取或者訂閱隊列中的消息。MQ和JMS類似管毙，但不同的是JMS是SUN JAVA消息中間件服務的一個標準和API定義腿椎，而MQ則是遵循了AMQP協(xié)議的具體實現(xiàn)和產品。

使用場景：

在項目中锅风，將一些無需即時返回且耗時的操作提取出來，進行了異步處理鞍泉，而這種異步處理的方式大大的節(jié)省了服務器的請求響應時間皱埠，從而提高了系統(tǒng)的吞吐量。

JMS簡介：

JMS即Java消息服務（Java Message Service）應用程序接口是一個Java平臺中關于面向消息中間件（MOM）的API咖驮，用于在兩個應用程序之間边器，或分布式系統(tǒng)中發(fā)送消息，進行異步通信托修。Java消息服務是一個與具體平臺無關的API忘巧，絕大多數(shù)MOM提供商都對JMS提供支持。

定義：

JMS（Java Messaging Service）是Java平臺上有關面向消息中間件(MOM)的技術規(guī)范睦刃，它便于消息系統(tǒng)中的Java應用程序進行消息交換,并且通過提供標準的產生砚嘴、發(fā)送、接收消息的接口簡化企業(yè)應用的開發(fā)，翻譯為Java消息服務际长。

簡介：

JMS是一種與廠商無關的 API耸采，用來訪問消息收發(fā)系統(tǒng)消息。它類似于JDBC(Java DatabaseConnectivity)：這里工育，JDBC 是可以用來訪問許多不同關系數(shù)據(jù)庫的 API虾宇，而 JMS 則提供同樣與廠商無關的訪問方法，以訪問消息收發(fā)服務如绸。許多廠商目前都支持JMS嘱朽，包括 IBM 的 MQSeries、BEA的 Weblogic JMS service和 Progress 的 SonicMQ怔接，這只是幾個例子搪泳。 JMS 使您能夠通過消息收發(fā)服務（有時稱為消息中介程序或路由器）從一個 JMS 客戶機向另一個JMS客戶機發(fā)送消息。消息是 JMS 中的一種類型對象蜕提，由兩部分組成：報頭和消息主體森书。報頭由路由信息以及有關該消息的元數(shù)據(jù)組成。消息主體則攜帶著應用程序的數(shù)據(jù)或有效負載谎势。根據(jù)有效負載的類型來劃分凛膏，可以將消息分為幾種類型，它們分別攜帶：簡單文本(TextMessage)脏榆、可序列化的對象 (ObjectMessage)猖毫、屬性集合 (MapMessage)、字節(jié)流 (BytesMessage)须喂、原始值流 (StreamMessage)吁断，還有無有效負載的消息 (Message)。

JMS和MQ的關系：

JMS是一個用于提供消息服務的技術規(guī)范坞生，它制定了在整個消息服務提供過程中的所有數(shù)據(jù)結構和交互流程仔役。而MQ則是消息隊列服務，是面向消息中間件（MOM）的最終實現(xiàn)是己，是真正的服務提供者又兵；MQ的實現(xiàn)可以基于JMS，也可以基于其他規(guī)范或標準卒废。

支持JMS的開源MQ：

目前選擇的最多的是ActiveMQ沛厨。

ActiveMQ 是Apache出品，最流行的摔认，能力強勁的開源消息總線逆皮。ActiveMQ 是一個完全支持JMS1.1和J2EE 1.4規(guī)范的 JMS Provider實現(xiàn),盡管JMS規(guī)范出臺已經是很久的事情了,但是JMS在當今的J2EE應用中間仍然扮演著特殊的地位。

主要特點：

1. 多種語言和協(xié)議編寫客戶端参袱。語言: Java, C, C++, C#, Ruby, Perl, Python, PHP电谣。應用協(xié)議: OpenWire,Stomp REST,WSNotification,XMPP,AMQP

2. 完全支持JMS1.1和J2EE 1.4規(guī)范 (持久化,XA消息,事務)

3. 對Spring的支持,ActiveMQ可以很容易內嵌到使用Spring的系統(tǒng)里面去,而且也支持Spring2.0的特性

4. 通過了常見J2EE服務器(如 Geronimo,JBoss 4, GlassFish,WebLogic)的測試,其中通過JCA 1.5 resource adaptors的配置,可以讓ActiveMQ可以自動的部署到任何兼容J2EE 1.4 商業(yè)服務器上

5. 支持多種傳送協(xié)議:in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA

6. 支持通過JDBC和journal提供高速的消息持久化

7. 從設計上保證了高性能的集群,客戶端-服務器,點對點

8. 支持Ajax

9. 支持與Axis的整合

10. 可以很容易得調用內嵌JMS provider,進行測試

11. ActiveMQ速度非郴嗝罚快；一般要比jbossMQ快10倍辰企。

優(yōu)點：

是一個快速的開源消息組件(框架)风纠，支持集群，同等網絡牢贸，自動檢測竹观，TCP，SSL潜索，廣播臭增，持久化，XA竹习，和J2EE1.4容器無縫結合誊抛，并且支持輕量級容器和大多數(shù)跨語言客戶端上的Java虛擬機。消息異步接受整陌，減少軟件多系統(tǒng)集成的耦合度拗窃。消息可靠接收，確保消息在中間件可靠保存泌辫，多個消息也可以組成原子事務随夸。

缺點：

ActiveMQ默認的配置性能偏低，需要優(yōu)化配置震放，但是配置文件復雜宾毒，ActiveMQ本身不提供管理工具；示例代碼少殿遂；主頁上的文檔看上去比較全面诈铛，但是缺乏一種有效的組織方式，文檔只有片段墨礁，用戶很難由淺入深進行了解幢竹，二、文檔整體的專業(yè)性太強恩静。在研究階段可以通過查maillist焕毫、看Javadoc、分析源代碼來了解蜕企。

ActiveMQ應用場景：

1咬荷、 不同語言應用集成

ActiveMQ 中間件用Java語言編寫冠句，因此自然提供Java客戶端 API轻掩。但是ActiveMQ 也為C/C++、.NET懦底、Perl唇牧、PHP罕扎、Python、Ruby 和一些其它語言提供客戶端丐重。在你考慮如何集成不同平臺不同語言編寫應用的時候腔召，ActiveMQ 擁有巨大優(yōu)勢。在這樣的例子中扮惦，多種客戶端API通過ActiveMQ 發(fā)送和接受消息成為可能臀蛛，無論使用的是什么語言。此外崖蜜，ActiveMQ 還提供交叉語言功能浊仆，該功能整合這種功能，無需使用遠程過程調用（RPC）確實是個優(yōu)勢豫领，因為消息協(xié)助應用解耦抡柿。

2、 作為RPC的替代

使用RPC同步調用的應用十分普遍等恐。假設大多數(shù)客戶端服務器應用使用RPC洲劣，包括ATM、大多數(shù)WEB應用课蔬、信用卡系統(tǒng)囱稽、銷售點系統(tǒng)等等。盡管很多系統(tǒng)很成功购笆，但是轉換使用異步消息可以帶來很多好處粗悯，而且也不會放棄響應保證。使用同步請求的系統(tǒng)在規(guī)模上有較大的限制同欠，因為請求會被阻塞样傍，從而導致整個系統(tǒng)變慢。如果使用異步消息替代铺遂，可以很容易增加額外的消息接收者衫哥，使得消息能被并發(fā)消耗，從而加快請求處理襟锐。當然撤逢，你的系統(tǒng)應用間應該是解耦的。

3粮坞、 應用之間解耦

正如之前討論的蚊荣，緊耦合架構可以導致很多問題，尤其是如果他們是分布的莫杈。松耦合架構互例，在另一方面，證實了更少的依賴性筝闹，能夠更好地處理不可預見的改變媳叨。不僅可以在系統(tǒng)中改變組件而不影響整個系統(tǒng)腥光，而且組件交互也相當?shù)暮唵巍Ｏ啾仁褂猛降南到y(tǒng)（調用者必須等待被調用者返回信息）糊秆，異步系統(tǒng)（調用方發(fā)送消息后就不管武福，即fire-and-forget）能夠給我們帶來事件驅動架構（event-driven architecture EDA）。

4痘番、 作為事件驅動架構的主干

解耦捉片，異步架構的系統(tǒng)允許通過代理器自己配置更多的客戶端，內存等（即vertical scalability）來擴大系統(tǒng)汞舱，而不是增加更多的代理器（即horizontal scalability）界睁。考慮如亞馬遜這樣繁忙的電子商務系統(tǒng)兵拢。當用戶購買物品翻斟，事實上系統(tǒng)需要很多步驟去處理，包括下單说铃，創(chuàng)建發(fā)票访惜，付款，執(zhí)行訂單腻扇，運輸?shù)日取５怯脩粝聠魏螅瑫⒓捶祷亍爸x謝你下單”的界面幼苛。不只是沒有延遲窒篱，而且用戶還會受到一封郵件表明訂單已經收到。在亞馬遜下單的例子就是一個多步處理的例子舶沿。每一步都由單獨的服務去處理墙杯。當用戶下單是，有一個同步的體積表單動作括荡，但整個處理流程并不通過瀏覽器同步處理高镐。相反地，訂單馬上被接受和反饋畸冲。而剩下的步驟就通過異步處理嫉髓。如果在處理過程中出錯，用戶會通過郵件收到通知邑闲。這樣的異步處理能提供高負載和高可用性算行。

5、 提高系統(tǒng)擴展性

很多使用事件驅動設計的系統(tǒng)是為了獲得高可擴展性苫耸，例如電子商務州邢，政府，制造業(yè)鲸阔，線上游戲等偷霉。通過異步消息分開商業(yè)處理步驟給各個應用，能夠帶來很多可能性褐筛±嗌伲考慮設計一個應用來完成一項特殊的任務。這就是面向服務的架構（service-oriented architecture SOA）渔扎。每一個服務完成一個功能并且只有一個功能硫狞。應用就通過服務組合起來，服務間使用異步消息和最終一致性晃痴。這樣的設計便可以引入一個復雜事件處理概念（complex event processing CEP）残吩。使用CEP，部件間的交互可以被記錄追蹤倘核。在異步消息系統(tǒng)中泣侮，可以很容易在部件間增加一層處理。

個人理解總結：

activeMQ是什么紧唱？

是Apache公司旗下的一個消息總線

ActiveMQ是一個開源兼容Java Message Service (JMS) 1.1面向消息的中件間. 來自Apache Software Foundation. ActiveMQ提供松耦合的應用程序架構.

activeMQ能干什么活尊？

用來在服務與服務之間進行異步通信的

activeMQ優(yōu)勢

1.流量肖鋒

2.任務異步處理

特點：可以解耦合

(學習新技術的三要素：是什么？能干什么漏益？有什么優(yōu)勢蛹锰？)

圖1：

image.png

通信模式：

1.點對點(queue)

》一個消息只能被一個服務接收

》消息一旦被消費，就會消失

》如果沒有被消費绰疤，就會一直等待铜犬，直到被消費

》多個服務監(jiān)聽同一個消費空間，先到先得

詳解：這個特點的原理是這樣的轻庆，在activeMQ

2.發(fā)布/訂閱模式(topic)

》一個消息可以被多個服務接收

》訂閱一個主題的消費者癣猾，只能消費自它訂閱之后發(fā)布的消息。

》消費端如果在生產端發(fā)送消息之后啟動余爆，是接收不到消息的煎谍，除非生產端對消息進行了持久化(例如廣播，只有當時聽到的人能聽到信息)

圖2：

image

注：消息是被推送和拉取的(消息生產端和消費端)龙屉，不是mq服務器去主動發(fā)送的

總：一些簡單常用的應用場景

1.發(fā)送郵件

詳解：

最經典的就是當用戶注冊時呐粘，我們就需要用activeMQ來做為中間件，當用戶注冊后转捕，我門把用戶的郵箱號和驗證碼等信息通過activeMQ的生產端發(fā)送到activeMQ的消息隊列中作岖，而一旦消息隊列中出現(xiàn)了數(shù)據(jù)，我們的郵件模塊通過實時的監(jiān)控activeMQ的消息隊列就能通過消費端獲取到這個數(shù)據(jù)五芝，染回郵件模塊就會自行的去對數(shù)據(jù)進行解析痘儡，給用戶發(fā)送郵件

2.發(fā)送短信

詳解：

原理同發(fā)送郵件相同

3.同步索引庫

詳解：

為了緩解數(shù)據(jù)庫的壓力，我們把經常被調用的數(shù)據(jù)放入索引庫中枢步，當有請求查詢時沉删，我們會先去查詢索引庫渐尿，如果索引庫內有數(shù)據(jù)，那么我們就不用就數(shù)據(jù)庫進行查詢矾瑰，這樣就能大大的減輕服務器的壓力砖茸，可是隨之而來的一個問題是，假如我們服務器內的數(shù)據(jù)已經發(fā)生了改變殴穴，而瀏覽用戶查詢數(shù)據(jù)時凉夯，因為索引庫中已經有數(shù)據(jù)了，那么這樣一來數(shù)據(jù)庫與索引庫的數(shù)據(jù)就不一致了采幌，那么怎么解決這個問題呢劲够？我們想到了通過用activeMQ來監(jiān)聽數(shù)據(jù)庫的操作來實現(xiàn)數(shù)據(jù)庫與索引庫的數(shù)據(jù)同步，當后臺管理員或房產經紀人對數(shù)據(jù)庫的數(shù)據(jù)進行了增刪改的操作時休傍，我們通過activeMQ監(jiān)聽到了數(shù)據(jù)的改變征绎，獲取到被修改的數(shù)據(jù)的id，然后在另一個服務模塊中通過這個數(shù)據(jù)的id去數(shù)據(jù)庫先查詢一把磨取，然后根據(jù)查詢結果進行判斷炒瘸，再去做索引庫的數(shù)據(jù)同步。打個比方寝衫，如果查詢結果返回的是空顷扩，就說明商品已經被刪除，那么我們就可以根據(jù)數(shù)據(jù)的id去把索引庫中的數(shù)據(jù)也一并刪除了慰毅。

4.同步靜態(tài)頁面

詳解：

此原理同上一個同步索引庫是一個原理隘截，目的都是為了減緩服務器的壓力，我們經過數(shù)據(jù)分析發(fā)現(xiàn)汹胃，其實我們的一些商品詳情頁面的數(shù)據(jù)其實都是大同小異的婶芭，完全可以通過freemarker頁面靜態(tài)化的模塊加上后臺查詢出的數(shù)據(jù)拼裝成一個靜態(tài)頁面，而這些數(shù)據(jù)從哪來呢着饥？我們經過討論和研究犀农，最后一致認為還是放在緩沖中比較好，這樣一來就能大大的減輕了數(shù)據(jù) 庫的壓力宰掉，而另一個好處是呵哨，由于頁面是純靜態(tài)頁面，所以頁面上的數(shù)據(jù)都是死數(shù)據(jù)轨奄，這樣一來就不用像JSP動態(tài)頁面那樣需要和后臺數(shù)據(jù)庫有大量的數(shù)據(jù)交互孟害，可以最大化的降低服務器的壓力，其實這個技術已經有很多大型公司在使用了挪拟，比如淘寶挨务，京東，網易等，我們要是細心一些就會發(fā)現(xiàn)谎柄，他們的頁面其實就都是HTML格式的靜態(tài)頁面丁侄。