MQ簡介：MQ全稱為Message Queue, 消息隊列（MQ）是一種應(yīng)用程序?qū)?yīng)用程序的通信方法。應(yīng)用程序通過寫和檢索出入列隊的針對應(yīng)用程序的數(shù)據(jù)（消息）來通信，而無需專用連接來鏈接它們。消息傳遞指的是程序之間通過在消息中發(fā)送數(shù)據(jù)進(jìn)行通信，而不是通過直接調(diào)用彼此來通信，直接調(diào)用通常是用于諸如遠(yuǎn)程過程調(diào)用的技術(shù)。排隊指的是應(yīng)用程序通過隊列來通信。隊列的使用除去了接收和發(fā)送應(yīng)用程序同時執(zhí)行的要求。其中較為成熟的MQ產(chǎn)品有IBMWEBSPHERE MQ。
MQ特點(diǎn)：
MQ的消費(fèi)-生產(chǎn)者模型的一個典型的代表，一端往消息隊列中不斷的寫入消息，而另一端則可以讀取或者訂閱隊列中的消息。MQ和JMS類似，但不同的是JMS是SUN Java消息中間件服務(wù)的一個標(biāo)準(zhǔn)和API定義，而MQ則是遵循了AMQP協(xié)議的具體實現(xiàn)和產(chǎn)品。
使用場景：
在項目中，將一些無需即時返回且耗時的操作提取出來，進(jìn)行了異步處理，而這種異步處理的方式大大的節(jié)省了服務(wù)器的請求響應(yīng)時間，從而提高了系統(tǒng)的吞吐量。
JMS簡介：
JMS即Java消息服務(wù)（Java Message Service）應(yīng)用程序接口是一個Java平臺中關(guān)于面向消息中間件（MOM）的API，用于在兩個應(yīng)用程序之間，或分布式系統(tǒng)中發(fā)送消息，進(jìn)行異步通信。Java消息服務(wù)是一個與具體平臺無關(guān)的API，絕大多數(shù)MOM提供商都對JMS提供支持。
定義：
JMS（Java Messaging Service）是Java平臺上有關(guān)面向消息中間件(MOM)的技術(shù)規(guī)范，它便于消息系統(tǒng)中的Java應(yīng)用程序進(jìn)行消息交換,并且通過提供標(biāo)準(zhǔn)的產(chǎn)生、發(fā)送、接收消息的接口簡化企業(yè)應(yīng)用的開發(fā)，翻譯為Java消息服務(wù)。
簡介：
JMS是一種與廠商無關(guān)的 API，用來訪問消息收發(fā)系統(tǒng)消息。它類似于JDBC(Java DatabaseConnectivity)：這里，JDBC 是可以用來訪問許多不同關(guān)系數(shù)據(jù)庫的 API，而 JMS 則提供同樣與廠商無關(guān)的訪問方法，以訪問消息收發(fā)服務(wù)。許多廠商目前都支持JMS，包括 IBM 的 MQSeries、BEA的 Weblogic JMS service和 Progress 的 SonicMQ，這只是幾個例子。 JMS 使您能夠通過消息收發(fā)服務(wù)（有時稱為消息中介程序或路由器）從一個 JMS 客戶機(jī)向另一個JMS客戶機(jī)發(fā)送消息。消息是 JMS 中的一種類型對象，由兩部分組成：報頭和消息主體。報頭由路由信息以及有關(guān)該消息的元數(shù)據(jù)組成。消息主體則攜帶著應(yīng)用程序的數(shù)據(jù)或有效負(fù)載。根據(jù)有效負(fù)載的類型來劃分，可以將消息分為幾種類型，它們分別攜帶：簡單文本(TextMessage)、可序列化的對象 (ObjectMessage)、屬性集合 (MapMessage)、字節(jié)流 (BytesMessage)、原始值流 (StreamMessage)，還有無有效負(fù)載的消息 (Message)。
JMS和MQ的關(guān)系：
JMS是一個用于提供消息服務(wù)的技術(shù)規(guī)范，它制定了在整個消息服務(wù)提供過程中的所有數(shù)據(jù)結(jié)構(gòu)和交互流程。而MQ則是消息隊列服務(wù)，是面向消息中間件（MOM）的最終實現(xiàn)，是真正的服務(wù)提供者；MQ的實現(xiàn)可以基于JMS，也可以基于其他規(guī)范或標(biāo)準(zhǔn)。
支持JMS的開源MQ：
目前選擇的最多的是ActiveMQ。
ActiveMQ 是Apache出品，最流行的，能力強(qiáng)勁的開源消息總線。ActiveMQ 是一個完全支持JMS1.1和J2EE 1.4規(guī)范的 JMS Provider實現(xiàn),盡管JMS規(guī)范出臺已經(jīng)是很久的事情了,但是JMS在當(dāng)今的J2EE應(yīng)用中間仍然扮演著特殊的地位。
主要特點(diǎn)：
- 多種語言和協(xié)議編寫客戶端。語言: Java, C, C++, C#, Ruby, Perl, Python, PHP。應(yīng)用協(xié)議: OpenWire,Stomp REST,WSNotification,XMPP,AMQP
- 完全支持JMS1.1和J2EE 1.4規(guī)范 (持久化,XA消息,事務(wù))
- 對spring的支持,ActiveMQ可以很容易內(nèi)嵌到使用Spring的系統(tǒng)里面去,而且也支持Spring2.0的特性
- 通過了常見J2EE服務(wù)器(如 Geronimo,JBoss 4, GlassFish,WebLogic)的測試,其中通過JCA 1.5 resource adaptors的配置,可以讓ActiveMQ可以自動的部署到任何兼容J2EE 1.4 商業(yè)服務(wù)器上
- 支持多種傳送協(xié)議:in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
- 支持通過JDBC和journal提供高速的消息持久化
- 從設(shè)計上保證了高性能的集群,客戶端-服務(wù)器,點(diǎn)對點(diǎn)
- 支持Ajax
- 支持與Axis的整合
- 可以很容易得調(diào)用內(nèi)嵌JMS provider,進(jìn)行測試
- ActiveMQ速度非常快；一般要比jbossMQ快10倍。
優(yōu)點(diǎn)：是一個快速的開源消息組件(框架)，支持集群，同等網(wǎng)絡(luò)，自動檢測，TCP，SSL，廣播，持久化，XA，和J2EE1.4容器無縫結(jié)合，并且支持輕量級容器和大多數(shù)跨語言客戶端上的Java虛擬機(jī)。消息異步接受，減少軟件多系統(tǒng)集成的耦合度。消息可靠接收，確保消息在中間件可靠保存，多個消息也可以組成原子事務(wù)。
缺點(diǎn)：ActiveMQ默認(rèn)的配置性能偏低，需要優(yōu)化配置，但是配置文件復(fù)雜，ActiveMQ本身不提供管理工具；示例代碼少；主頁上的文檔看上去比較全面，但是缺乏一種有效的組織方式，文檔只有片段，用戶很難由淺入深進(jìn)行了解，二、文檔整體的專業(yè)性太強(qiáng)。在研究階段可以通過查maillist、看Javadoc、分析源代碼來了解。
ActiveMQ應(yīng)用場景：
1、 不同語言應(yīng)用集成
ActiveMQ 中間件用Java語言編寫，因此自然提供Java客戶端 API。但是ActiveMQ 也為C/C++、.NET、Perl、PHP、Python、Ruby 和一些其它語言提供客戶端。在你考慮如何集成不同平臺不同語言編寫應(yīng)用的時候，ActiveMQ 擁有巨大優(yōu)勢。在這樣的例子中，多種客戶端API通過ActiveMQ 發(fā)送和接受消息成為可能，無論使用的是什么語言。此外，ActiveMQ 還提供交叉語言功能，該功能整合這種功能，無需使用遠(yuǎn)程過程調(diào)用（RPC）確實是個優(yōu)勢，因為消息協(xié)助應(yīng)用解耦。
2、 作為RPC的替代
使用RPC同步調(diào)用的應(yīng)用十分普遍。假設(shè)大多數(shù)客戶端服務(wù)器應(yīng)用使用RPC，包括ATM、大多數(shù)WEB應(yīng)用、信用卡系統(tǒng)、銷售點(diǎn)系統(tǒng)等等。盡管很多系統(tǒng)很成功，但是轉(zhuǎn)換使用異步消息可以帶來很多好處，而且也不會放棄響應(yīng)保證。使用同步請求的系統(tǒng)在規(guī)模上有較大的限制，因為請求會被阻塞，從而導(dǎo)致整個系統(tǒng)變慢。如果使用異步消息替代，可以很容易增加額外的消息接收者，使得消息能被并發(fā)消耗，從而加快請求處理。當(dāng)然，你的系統(tǒng)應(yīng)用間應(yīng)該是解耦的。
3、 應(yīng)用之間解耦
正如之前討論的，緊耦合架構(gòu)可以導(dǎo)致很多問題，尤其是如果他們是分布的。松耦合架構(gòu)，在另一方面，證實了更少的依賴性，能夠更好地處理不可預(yù)見的改變。不僅可以在系統(tǒng)中改變組件而不影響整個系統(tǒng)，而且組件交互也相當(dāng)?shù)暮唵巍Ｏ啾仁褂猛降南到y(tǒng)（調(diào)用者必須等待被調(diào)用者返回信息），異步系統(tǒng)（調(diào)用方發(fā)送消息后就不管，即fire-and-forget）能夠給我們帶來事件驅(qū)動架構(gòu)（event-driven architecture EDA）。
4、 作為事件驅(qū)動架構(gòu)的主干
解耦，異步架構(gòu)的系統(tǒng)允許通過代理器自己配置更多的客戶端，內(nèi)存等（即vertical scalability）來擴(kuò)大系統(tǒng)，而不是增加更多的代理器（即horizontal scalability）。考慮如亞馬遜這樣繁忙的電子商務(wù)系統(tǒng)。當(dāng)用戶購買物品，事實上系統(tǒng)需要很多步驟去處理，包括下單，創(chuàng)建發(fā)票，付款，執(zhí)行訂單，運(yùn)輸?shù)取５怯脩粝聠魏螅瑫⒓捶祷亍爸x謝你下單”的界面。不只是沒有延遲，而且用戶還會受到一封郵件表明訂單已經(jīng)收到。在亞馬遜下單的例子就是一個多步處理的例子。每一步都由單獨(dú)的服務(wù)去處理。當(dāng)用戶下單是，有一個同步的體積表單動作，但整個處理流程并不通過瀏覽器同步處理。相反地，訂單馬上被接受和反饋。而剩下的步驟就通過異步處理。如果在處理過程中出錯，用戶會通過郵件收到通知。這樣的異步處理能提供高負(fù)載和高可用性。
5、 提高系統(tǒng)擴(kuò)展性
很多使用事件驅(qū)動設(shè)計的系統(tǒng)是為了獲得高可擴(kuò)展性，例如電子商務(wù)，政府，制造業(yè)，線上游戲等。通過異步消息分開商業(yè)處理步驟給各個應(yīng)用，能夠帶來很多可能性。考慮設(shè)計一個應(yīng)用來完成一項特殊的任務(wù)。這就是面向服務(wù)的架構(gòu)（service-oriented architecture SOA）。每一個服務(wù)完成一個功能并且只有一個功能。應(yīng)用就通過服務(wù)組合起來，服務(wù)間使用異步消息和最終一致性。這樣的設(shè)計便可以引入一個復(fù)雜事件處理概念（complex event processing CEP）。使用CEP，部件間的交互可以被記錄追蹤。在異步消息系統(tǒng)中，可以很容易在部件間增加一層處理。
其他開源JMS供應(yīng)商；
jbossmq(jboss 4)
jboss messaging (jboss 5)
joram-4.3.21 2006-09-22
openjms-0.7.7-alpha-3.zipDecember 26,2005
mantamq
ubermq
SomnifugiJMS 2005-7-27
開源的JMSProvider大部分都已經(jīng)停止發(fā)展了，剩下的幾個都是找到了東家，和某種J2EE 服務(wù)器掛鉤，比如jbossmq 與jboss,joram與jonas(objectweb組織），ActiveMQ 與Geronimo(ASF APACHE基金組織），而在這3個之間，從網(wǎng)絡(luò)底層來看，只有ActiveMQ使用了NIO，單從這個角度來看ActiveMQ在性能上會有一定的優(yōu)勢。
