MQ消息中間件技術

AMQP協定介紹

AMQP，即Advanced Message Queuing Protocol，進階消息隊列協定，是應用層協定的一個開放标準，為面向消息的中間件設計。

AMQP的主要特征是面向消息、隊列、路由（包括點對點和釋出/訂閱）、可靠性、安全。

AMQP在消息提供者和用戶端的行為進行了強制規定，使得不同賣商之間真正實作了互操作能力。

JMS是早期消息中間件進行标準化的一個嘗試，它僅僅是在API級進行了規範，離建立互操作能力還差很遠。

與JMS不同，AMQP是一個Wire級的協定，它描述了在網絡上傳輸的資料的格式，以位元組為流。是以任何遵守此資料格式的工具，其建立和解釋消息，都能與其他相容工具進行互操作。

AMQP規範的版本：

0-8        是2006年6月釋出

0-9        于2006年12月釋出

0-9-1     于2008年11月釋出

0-10      于2009年下半年釋出

1.0 draft  （文檔還是草案）

AMQP的實作有：

1）OpenAMQ

AMQP的開源實作，用C語言編寫，運作于Linux、AIX、Solaris、Windows、OpenVMS。

2）Apache Qpid

Apache的開源項目，支援C++、Ruby、Java、JMS、Python和.NET。

3）Redhat Enterprise MRG

實作了AMQP的最新版本0-10，提供了豐富的特征集，比如完全管理、聯合、Active-Active叢集，有Web控制台，還有許多企業級特征，用戶端支援C++、Ruby、Java、JMS、Python和.NET。

4）RabbitMQ

一個獨立的開源實作，伺服器端用Erlang語言編寫，支援多種用戶端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支援AJAX。RabbitMQ釋出在Ubuntu、FreeBSD平台。

5）AMQP Infrastructure

Linux下，包括Broker、管理工具、Agent和用戶端。

6）ØMQ

一個高性能的消息平台，在分布式消息網絡可作為相容AMQP的Broker節點，綁定了多種語言，包括Python、C、C++、Lisp、Ruby等。

7）Zyre

是一個Broker，實作了RestMS協定和AMQP協定，提供了RESTful HTTP通路網絡AMQP的能力。

JMS協定介紹

JMS（Java Messaging Service）是Java平台上有關面向消息中間件的技術規範，它便于消息系統中的Java應用程式進行消息交換,并且通過提供标準的産生、發送、接收消息的接口簡化企業應用的開發。

       JMS本身隻定義了一系列的接口規範，是一種與廠商無關的 API，用來通路消息收發系統。它類似于 JDBC(Java Database Connectivity)：這裡，JDBC 是可以用來通路許多不同關系資料庫的 API，而 JMS 則提供同樣與廠商無關的通路方法，以通路消息收發服務。許多廠商目前都支援 JMS，包括 IBM 的 MQSeries、BEA的 Weblogic JMS service和 Progress 的 SonicMQ，這隻是幾個例子。 JMS 使您能夠通過消息收發服務（有時稱為消息中介程式或路由器）從一個 JMS 客戶機向另一個 JML 客戶機發送消息。消息是 JMS 中的一種類型對象，由兩部分組成：報頭和消息主體。報頭由路由資訊以及有關該消息的中繼資料組成。消息主體則攜帶着應用程式的資料或有效負載。根據有效負載 的類型來劃分，可以将消息分為幾種類型，它們分别攜帶：簡單文本 (TextMessage)、可序列化的對象 (ObjectMessage)、屬性集合 (MapMessage)、位元組流 (BytesMessage)、原始值流 (StreamMessage)，還有無有效負載的消息 (Message)。

STOMP協定介紹

STOMP，Streaming Text Orientated Message Protocol，是流文本定向消息協定，是一種為MOM(Message Oriented Middleware，面向消息的中間件)設計的簡單文本協定。

它提供了一個可互操作的連接配接格式，允許STOMP用戶端與任意STOMP消息代理(Broker)進行互動，類似于OpenWire(一種二進制協定)。

由于其設計簡單，很容易開發用戶端，是以在多種語言和多種平台上得到廣泛應用。其中最流行的STOMP消息代理是Apache ActiveMQ。

STOMP協定工作于TCP協定之上，使用了下列指令：

    * SEND 發送

    * SUBSCRIBE 訂閱

    * UNSUBSCRIBE 退訂

    * BEGIN 開始

    * COMMIT 送出

    * ABORT 取消

    * ACK 确認

    * DISCONNECT 斷開

消息中間件概況

消息隊列技術是分布式應用間交換資訊的一種技術。消息隊列可駐留在記憶體或磁盤上,隊列存儲消息直到它們被應用程式讀走。通過消息隊列，應用程式可獨立地執行--它們不需要知道彼此的位置、或在繼續執行前不需要等待接收程式接收此消息。

       在分布式計算環境中，為了內建分布式應用，開發者需要對異構網絡環境下的分布式應用提供有效的通信手段。為了管理需要共享的資訊，對應用提供公共的資訊交換機制是重要的。

       設計分布式應用的方法主要有：遠端過程調用(PRC)-分布式計算環境(DCE)的基礎标準成分之一；對象事務監控(OTM)-基于CORBA的面向對象工業标準與事務處理(TP)監控技術的組合；消息隊列(MessageQueue)-構造分布式應用的松耦合方法。

       (a) 分布計算環境/遠端過程調用 (DCE/RPC)

       RPC是DCE的成分，是一個由開放軟體基金會(OSF)釋出的應用內建的軟體标準。RPC模仿一個程式用函數引用來引用另一程式的傳統程式設計方法，此引用是過程調用的形式，一旦被調用，程式的控制則轉向被調用程式。

       在RPC 實作時，被調用過程可在本地或遠地的另一系統中駐留并在執行。當被調用程式完成處理輸入資料，結果放在過程調用的傳回變量中傳回到調用程式。RPC完成後程式控制則立即傳回到調用程式。是以RPC模仿子程式的調用/傳回結構，它僅提供了Client(調用程式)和Server(被調用過程)間的同步資料交換。

       (b) 對象事務監控 (OTM)

       基于CORBA的面向對象工業标準與事務處理(TP)監控技術的組合，在CORBA規範中定義了：使用面向對象技術和方法的體系結構；公共的 Client/Server程式設計接口；多平台間傳輸和翻譯資料的指導方針；開發分布式應用接口的語言(IDL)等，并為構造分布的 Client/Server應用提供了廣泛及一緻的模式。

       (c) 消息隊列 (Message Queue)

       消息隊列為構造以同步或異步方式實作的分布式應用提供了松耦合方法。消息隊列的API調用被嵌入到新的或現存的應用中，通過消息發送到記憶體或基于磁盤的隊列或從它讀出而提供資訊交換。消息隊列可用在應用中以執行多種功能，比如要求服務、交換資訊或異步處理等。

       中間件是一種獨立的系統軟體或服務程式，分布式應用系統借助這種軟體在不同的技術之間共享資源，管理計算資源和網絡通訊。它在計算機系統中是一個關鍵軟體，它能實作應用的互連和互操作性，能保證系統的安全、可靠、高效的運作。中間件位于使用者應用和作業系統及網絡軟體之間，它為應用提供了公用的通信手段，并且獨立于網絡和作業系統。中間件為開發者提供了公用于所有環境的應用程式接口，當應用程式中嵌入其函數調用，它便可利用其運作的特定作業系統和網絡環境的功能，為應用執行通信功能。

       如果沒有消息中間件完成資訊交換，應用開發者為了傳輸資料，必須要學會如何用網絡和作業系統軟體的功能，編寫相應的應用程式來發送和接收資訊，且交換資訊沒有标準方法，每個應用必須進行特定的程式設計進而和多平台、不同環境下的一個或多個應用通信。例如，為了實作網絡上不同主機系統間的通信，将要求具備在網絡上如何交換資訊的知識（比如用TCP/IP的socket程式設計）；為了實作同一主機内不同程序之間的通訊，将要求具備作業系統的消息隊列或命名管道(Pipes)等知識。

       目前中間件的種類很多，如交易管理中間件、面向Java應用的Web應用伺服器中間件等，而消息傳輸中間件(MOM)是其中的一種。它簡化了應用之間資料的傳輸，屏蔽底層異構作業系統和網絡平台，提供一緻的通訊标準和應用開發，確定分布式計算網絡環境下可靠的、跨平台的資訊傳輸和資料交換。它基于消息隊列的存儲-轉發機制，并提供特有的異步傳輸機制，能夠基于消息傳輸和異步事務處理實作應用整合與資料交換。

釋出-訂閱消息模式

一、 訂閱雜志

      我們很多人都訂過雜志，其過程很簡單。隻要告訴郵局我們所要訂的雜志名、投遞的位址，付了錢就OK。出版社定期會将出版的雜志交給郵局，郵局會根據訂閱的清單，将雜志送達消費者手中。這樣我們就可以看到每一期精彩的雜志了。

仔細思考一下訂雜志的過程，我們會發現這樣幾個特點：1、 消費者訂雜志不需要直接找出版社；2、 出版社隻需要把雜志交給郵局；3、 郵局将雜志送達消費者。郵局在整個過程中扮演了非常重要的中轉作用，在出版社和消費者互相不需要知道對方的情況下，郵局完成了雜志的投遞。

二、 釋出-訂閱消息模式

       剛剛講了訂閱雜志，下面我們會講傳統調用模式演化到釋出-訂閱消息模式。

       有些網站在注冊使用者成功後發一封激活郵件，使用者收到郵件後點選激活連結後才能使用該網站。一般的做法是在注冊使用者業務邏輯中調用發送郵件的邏輯。這 樣使用者業務就依賴于郵件業務。如果以後改為短信激活，注冊使用者業務邏輯就必須修改為調用發送短信的邏輯。如果要注冊後給使用者加點積分，再加一段邏輯。經過 多次修改，我們發現很簡單的注冊使用者業務已經越來越複雜，越來越難以維護。相信很多開發者都會有類似痛苦的經曆。

即使使用者業務實作中對其他業務是接口依賴，也避免不了業務變化帶來的依賴影響。怎麼辦？解耦！将注冊使用者業務邏輯中注冊成功後的處理剝離出來。

       再回頭看看"訂閱雜志"，如果沒有郵局，出版社就必須自己将雜志送達所有消費者。這種情形就和現在的注冊使用者業務一樣。我們發現問題了，在使用者業務和其他業務之間缺少了郵局所扮角色。

       我們把郵局抽象成一個管理消息的地方，叫"消息管理器"。注冊使用者成功後發送一個消息給消息管理器，由消息管理器轉發該消息給需要處理的業務。現在，使用者業務隻依賴于消息管理器了，它再也不會為了注冊使用者成功後的其他處理而煩惱。

注冊使用者的改造就是借鑒了"訂閱雜志"這樣原始的模式。我們再進一步抽象，使用者業務就是消息的"生産者"，它将消息釋出到消息管理器。郵件業務就是 消息的"消費者"，它将收到的消息進行處理。郵局可以訂閱很多種雜志，雜志都是通過某種編号來區分；消息管理器也可以管理多種消息，每種消息都會有一個 "主題"來區分，消費者都是通過主題來訂閱的。

釋出-訂閱消息模式已經呈現在我們面前，利用它可以産生更靈活、更松散耦合的系統。

MQ相關概念

1.消息(Message)

消息是MQ中最小的概念，本質上就是一段資料，它能被一個或者多個應用程式所了解，是應用程式之間傳遞的資訊載體。

2.隊列(Queue）

2.1本地隊列

本地隊列按照功能可劃分為初始化隊列，傳輸隊列，目标隊列和死信隊列。

初始化隊列用作消息觸發功能。

傳輸隊列隻是暫存待傳的消息，條件許可的情況下，通過管道将消息傳送到其他的隊列管理器。

目标隊列是消息的目的地，可以長期存放消息。

如果消息不能送達目标隊列，也不能再路由出去，則被自動放入死信隊列儲存。

2.2别名隊列&遠端隊列

隻是一個隊列定義，用來指定遠端隊列管理器的隊列。使用了遠端隊列，程式就不需要知道目标隊列的位置。

2.3模型隊列

模型隊列定義了一套本地隊列的屬性結合，一旦打開模型隊列，隊列管理器會按照這些屬性動态地建立出一個本地隊列。

3.隊列管理器(Queue Manager)

隊列管理器是一個負責向應用程式提供消息服務的機構，如果把隊列管理器比作資料庫，那麼隊列就是其中一張表。

4.通道(Channel)

通道是兩個管理器之間的一種單向點對點的的通信連接配接，如果需要雙向交流，可以建立一對通道。

5.監聽器(listner)

MQ産品的特性

可靠性傳輸

這個特點可以說是消息中間件的立足之本，對于應用來說，隻要成功把資料送出給消息中間件，那麼關于資料可靠傳輸的問題就由消息中間件來負責。

不重複傳輸

不重複傳播也就是斷點續傳的功能，特别适合網絡不穩定的環境，節約網絡資源。

異步性傳輸

異步性傳輸是指，接受資訊雙方不必同時線上，具有脫機能力和安全性。

消息驅動

接到消息後主動通知消息接收方。

支援事務

應用程式可以把一些資料更新組合成一個工作單元，這些更新通常是邏輯相關的，為了保障資料完整性，所有的更新必須同時成功或者同時失敗）。 

常用MQ産品比較

ActiveMQ	Joram	HornetQ	OpenMQ	MuleMQ	SonicMQ	RabbitMQ	ZeroMQ
關注度	高	中	中	中	低	低	高	中
成熟度	成熟	比較成熟	比較成熟	比較成熟	新産品無成功案例	成熟	成熟	不成熟
所屬社群/公司	Apache	OW2	Jboss	Sun	Mule	Progress
社群活躍度	高	中	中	低	高	低	高	低
文檔	多	多	中	中	少	少	多	中
特點	功能齊全，被大量開源項目使用	在Linux平台上直接調用作業系統的AIO，性能得到很大的提升	性能非常好，與MuleESB無縫整合	性能優越的商業MQ	由于Erlang語言的并發能力，性能很好	低延時，高性能，最高43萬條消息每秒
授權方式	開源	開源	開源	開源	商業	商業	開源	開源
開發語言	Java	Java	Java	Java	Java	Java	Erlang	C
支援的協定	OpenWire、STOMP、REST、XMPP、AMQP	JMS	JMS	JMS	JMS	JMS	AMQP	TCP、UDP
用戶端支援語言	Java、C、C++、Python、PHP、Perl、.net等	Java	Java	Java	Java	Java、C、C++、.net	Java、C、C++、Python、PHP、Perl等	python、java、php、.net等
持久化	記憶體、檔案、資料庫	記憶體、檔案	記憶體、檔案	記憶體、檔案	記憶體、檔案	記憶體、檔案、資料庫	記憶體、檔案	在消息發送端儲存
事務	支援	支援	支援	支援	支援	支援	不支援	不支援
叢集	支援	支援	支援	支援	支援	支援	支援	不支援
負載均衡	支援	支援	支援	支援	支援	支援	支援	不支援
管理界面	一般	一般	無	一般	一般	好	無	無
部署方式	獨立、嵌入	獨立、嵌入	獨立、嵌入	獨立、嵌入	獨立	獨立	獨立	獨立
評價	成熟穩定，開源首選	依賴容器，不适合跨語言調用	推出的時間不長，尚無使用案例，不适合跨語言調用	依賴容器，不适合跨語言調用	推出的時間不長，無成功案例，目前僅支援Java	成熟穩定	Queue的數量大于50後，高并發下無法持續穩定的提供服務	不支援事務、叢集，并且消息不能在服務端持久化

MQ适用場景介紹

MQ消息隊列是應運松偶合的概念而産生的，主要以隊列和釋出訂閱為消息傳輸機制，以異步的方式将消息可靠的傳輸到消費端的一種基礎産品。

它被廣泛的應用與跨平台、跨系統的分布式系統之間，為它們提供高效可靠的異步傳輸機制。

• 消息通道（Message Channel）

       使用MQ将彼此協作的用戶端和服務端連接配接起來，使他們可以交換消息。

如用戶端與服務端需要安全可靠的互動，可以将一個MQ的隊列作為安全通道，是用戶端與服務端能夠安全高效的進行異步通訊。

• 消息總線（Message Bus）

      對于由許多獨立開發的服務組成的分布式系統，倘若要将它們組成一個完整的系統，這些服務必須能夠可靠地互動，同時，為了系統的健壯性，

每個服務之間又不能産生過分緊密的依賴關系，這樣就可以通過消息總線将不同的服務連接配接起來，允許它們異步的傳遞資料。

• 消息路由（Message Router）

       通過消息路由，可以将發送到MQ指定隊列的消息根據規則路由到不同的隊列。

此外，JMS規範還支援通過selector條件，對消息進行過濾，可以用多個消費者消費同一個隊列的消息，每個消費者隻消費自己感興趣的消息。

• 釋出/訂閱（Publicsher/Subscriber）

      釋出/訂閱模式用于一對多的通訊，當消息釋出者向一個主題（Topic）發送一條消息後，該主題的所有訂閱者都會收到這條消息。

原位址：http://blog.csdn.net/apanious/article/details/51014396