轉(zhuǎn)載自：http://blog.csdn.net/wxyfighting/article/details/8866437

AMQP協(xié)議介紹
AMQP，即Advanced Message Queuing Protocol，高級消息隊列協(xié)議，是應(yīng)用層協(xié)議的一個開放標(biāo)準(zhǔn)，為面向消息的中間件設(shè)計。

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

AMQP在消息提供者和客戶端的行為進(jìn)行了強(qiáng)制規(guī)定，使得不同賣商之間真正實現(xiàn)了互操作能力。

JMS是早期消息中間件進(jìn)行標(biāo)準(zhǔn)化的一個嘗試，它僅僅是在API級進(jìn)行了規(guī)范，離創(chuàng)建互操作能力還差很遠(yuǎn)。

與JMS不同，AMQP是一個Wire級的協(xié)議，它描述了在網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)的格式，以字節(jié)為流。因此任何遵守此數(shù)據(jù)格式的工具，其創(chuàng)建和解釋消息，都能與其他兼容工具進(jìn)行互操作。

AMQP規(guī)范的版本：
0-8 是2006年6月發(fā)布
0-9 于2006年12月發(fā)布
0-9-1 于2008年11月發(fā)布
0-10 于2009年下半年發(fā)布
1.0 draft （文檔還是草案）

AMQP的實現(xiàn)有：

1）OpenAMQ
AMQP的開源實現(xiàn)，用C語言編寫，運行于Linux、AIX、Solaris、Windows、OpenVMS。

2）Apache Qpid
Apache的開源項目，支持C++、Ruby、Java、JMS、Python和.NET。

3）Redhat Enterprise MRG
實現(xiàn)了AMQP的最新版本0-10，提供了豐富的特征集，比如完全管理、聯(lián)合、Active-Active集群，有Web控制臺，還有許多企業(yè)級特征，客戶端支持C++、Ruby、Java、JMS、Python和.NET。

4）RabbitMQ
一個獨立的開源實現(xiàn)，服務(wù)器端用Erlang語言編寫，支持多種客戶端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX。RabbitMQ發(fā)布在Ubuntu、FreeBSD平臺。

5）AMQP Infrastructure
Linux下，包括Broker、管理工具、Agent和客戶端。

6）?MQ
一個高性能的消息平臺，在分布式消息網(wǎng)絡(luò)可作為兼容AMQP的Broker節(jié)點，綁定了多種語言，包括Python、C、C++、Lisp、Ruby等。

7）Zyre
是一個Broker，實現(xiàn)了RestMS協(xié)議和AMQP協(xié)議，提供了RESTful HTTP訪問網(wǎng)絡(luò)AMQP的能力。

JMS協(xié)議介紹
JMS（Java Messaging Service）是Java平臺上有關(guān)面向消息中間件的技術(shù)規(guī)范，它便于消息系統(tǒng)中的Java應(yīng)用程序進(jìn)行消息交換,并且通過提供標(biāo)準(zhǔn)的產(chǎn)生、發(fā)送、接收消息的接口簡化企業(yè)應(yīng)用的開發(fā)。

   JMS本身只定義了一系列的接口規(guī)范，是一種與廠商無關(guān)的 API，用來訪問消息收發(fā)系統(tǒng)。它類似于 JDBC(Java Database Connectivity)：這里，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ī)向另一個 JML 客戶機(jī)發(fā)送消息。消息是 JMS 中的一種類型對象，由兩部分組成：報頭和消息主體。報頭由路由信息以及有關(guān)該消息的元數(shù)據(jù)組成。消息主體則攜帶著應(yīng)用程序的數(shù)據(jù)或有效負(fù)載。根據(jù)有效負(fù)載 的類型來劃分，可以將消息分為幾種類型，它們分別攜帶：簡單文本 (TextMessage)、可序列化的對象 (ObjectMessage)、屬性集合 (MapMessage)、字節(jié)流 (BytesMessage)、原始值流 (StreamMessage)，還有無有效負(fù)載的消息 (Message)。

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

它提供了一個可互操作的連接格式，允許STOMP客戶端與任意STOMP消息代理(Broker)進(jìn)行交互，類似于OpenWire(一種二進(jìn)制協(xié)議)。

由于其設(shè)計簡單，很容易開發(fā)客戶端，因此在多種語言和多種平臺上得到廣泛應(yīng)用。其中最流行的STOMP消息代理是Apache ActiveMQ。

STOMP協(xié)議工作于TCP協(xié)議之上，使用了下列命令：

* SEND 發(fā)送
* SUBSCRIBE 訂閱
* UNSUBSCRIBE 退訂
* BEGIN 開始
* COMMIT 提交
* ABORT 取消
* ACK 確認(rèn)
* DISCONNECT 斷開

消息中間件概況
消息隊列技術(shù)是分布式應(yīng)用間交換信息的一種技術(shù)。消息隊列可駐留在內(nèi)存或磁盤上,隊列存儲消息直到它們被應(yīng)用程序讀走。通過消息隊列，應(yīng)用程序可獨立地執(zhí)行–它們不需要知道彼此的位置、或在繼續(xù)執(zhí)行前不需要等待接收程序接收此消息。

   在分布式計算環(huán)境中，為了集成分布式應(yīng)用，開發(fā)者需要對異構(gòu)網(wǎng)絡(luò)環(huán)境下的分布式應(yīng)用提供有效的通信手段。為了管理需要共享的信息，對應(yīng)用提供公共的信息交換機(jī)制是重要的。

   設(shè)計分布式應(yīng)用的方法主要有：遠(yuǎn)程過程調(diào)用(PRC)-分布式計算環(huán)境(DCE)的基礎(chǔ)標(biāo)準(zhǔn)成分之一；對象事務(wù)監(jiān)控(OTM)-基于CORBA的面向?qū)ο蠊I(yè)標(biāo)準(zhǔn)與事務(wù)處理(TP)監(jiān)控技術(shù)的組合；消息隊列(MessageQueue)-構(gòu)造分布式應(yīng)用的松耦合方法。

   (a) 分布計算環(huán)境/遠(yuǎn)程過程調(diào)用 (DCE/RPC)

   RPC是DCE的成分，是一個由開放軟件基金會(OSF)發(fā)布的應(yīng)用集成的軟件標(biāo)準(zhǔn)。RPC模仿一個程序用函數(shù)引用來引用另一程序的傳統(tǒng)程序設(shè)計方法，此引用是過程調(diào)用的形式，一旦被調(diào)用，程序的控制則轉(zhuǎn)向被調(diào)用程序。

   在RPC 實現(xiàn)時，被調(diào)用過程可在本地或遠(yuǎn)地的另一系統(tǒng)中駐留并在執(zhí)行。當(dāng)被調(diào)用程序完成處理輸入數(shù)據(jù)，結(jié)果放在過程調(diào)用的返回變量中返回到調(diào)用程序。RPC完成后程序控制則立即返回到調(diào)用程序。因此RPC模仿子程序的調(diào)用/返回結(jié)構(gòu)，它僅提供了Client(調(diào)用程序)和Server(被調(diào)用過程)間的同步數(shù)據(jù)交換。

   (b) 對象事務(wù)監(jiān)控 (OTM)

   基于CORBA的面向?qū)ο蠊I(yè)標(biāo)準(zhǔn)與事務(wù)處理(TP)監(jiān)控技術(shù)的組合，在CORBA規(guī)范中定義了：使用面向?qū)ο蠹夹g(shù)和方法的體系結(jié)構(gòu)；公共的 Client/Server程序設(shè)計接口；多平臺間傳輸和翻譯數(shù)據(jù)的指導(dǎo)方針；開發(fā)分布式應(yīng)用接口的語言(IDL)等，并為構(gòu)造分布的 Client/Server應(yīng)用提供了廣泛及一致的模式。

   (c) 消息隊列 (Message Queue)

   消息隊列為構(gòu)造以同步或異步方式實現(xiàn)的分布式應(yīng)用提供了松耦合方法。消息隊列的API調(diào)用被嵌入到新的或現(xiàn)存的應(yīng)用中，通過消息發(fā)送到內(nèi)存或基于磁盤的隊列或從它讀出而提供信息交換。消息隊列可用在應(yīng)用中以執(zhí)行多種功能，比如要求服務(wù)、交換信息或異步處理等。

   中間件是一種獨立的系統(tǒng)軟件或服務(wù)程序，分布式應(yīng)用系統(tǒng)借助這種軟件在不同的技術(shù)之間共享資源，管理計算資源和網(wǎng)絡(luò)通訊。它在計算機(jī)系統(tǒng)中是一個關(guān)鍵軟件，它能實現(xiàn)應(yīng)用的互連和互操作性，能保證系統(tǒng)的安全、可靠、高效的運行。中間件位于用戶應(yīng)用和操作系統(tǒng)及網(wǎng)絡(luò)軟件之間，它為應(yīng)用提供了公用的通信手段，并且獨立于網(wǎng)絡(luò)和操作系統(tǒng)。中間件為開發(fā)者提供了公用于所有環(huán)境的應(yīng)用程序接口，當(dāng)應(yīng)用程序中嵌入其函數(shù)調(diào)用，它便可利用其運行的特定操作系統(tǒng)和網(wǎng)絡(luò)環(huán)境的功能，為應(yīng)用執(zhí)行通信功能。

   如果沒有消息中間件完成信息交換，應(yīng)用開發(fā)者為了傳輸數(shù)據(jù)，必須要學(xué)會如何用網(wǎng)絡(luò)和操作系統(tǒng)軟件的功能，編寫相應(yīng)的應(yīng)用程序來發(fā)送和接收信息，且交換信息沒有標(biāo)準(zhǔn)方法，每個應(yīng)用必須進(jìn)行特定的編程從而和多平臺、不同環(huán)境下的一個或多個應(yīng)用通信。例如，為了實現(xiàn)網(wǎng)絡(luò)上不同主機(jī)系統(tǒng)間的通信，將要求具備在網(wǎng)絡(luò)上如何交換信息的知識（比如用TCP/IP的socket程序設(shè)計）；為了實現(xiàn)同一主機(jī)內(nèi)不同進(jìn)程之間的通訊，將要求具備操作系統(tǒng)的消息隊列或命名管道(Pipes)等知識。

   目前中間件的種類很多，如交易管理中間件、面向Java應(yīng)用的Web應(yīng)用服務(wù)器中間件等，而消息傳輸中間件(MOM)是其中的一種。它簡化了應(yīng)用之間數(shù)據(jù)的傳輸，屏蔽底層異構(gòu)操作系統(tǒng)和網(wǎng)絡(luò)平臺，提供一致的通訊標(biāo)準(zhǔn)和應(yīng)用開發(fā)，確保分布式計算網(wǎng)絡(luò)環(huán)境下可靠的、跨平臺的信息傳輸和數(shù)據(jù)交換。它基于消息隊列的存儲-轉(zhuǎn)發(fā)機(jī)制，并提供特有的異步傳輸機(jī)制，能夠基于消息傳輸和異步事務(wù)處理實現(xiàn)應(yīng)用整合與數(shù)據(jù)交換。

發(fā)布-訂閱消息模式
一、 訂閱雜志

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

仔細(xì)思考一下訂雜志的過程，我們會發(fā)現(xiàn)這樣幾個特點：1、 消費者訂雜志不需要直接找出版社；2、 出版社只需要把雜志交給郵局；3、 郵局將雜志送達(dá)消費者。郵局在整個過程中扮演了非常重要的中轉(zhuǎn)作用，在出版社和消費者相互不需要知道對方的情況下，郵局完成了雜志的投遞。
二、 發(fā)布-訂閱消息模式

   剛剛講了訂閱雜志，下面我們會講傳統(tǒng)調(diào)用模式演化到發(fā)布-訂閱消息模式。
   有些網(wǎng)站在注冊用戶成功后發(fā)一封激活郵件，用戶收到郵件后點擊激活鏈接后才能使用該網(wǎng)站。一般的做法是在注冊用戶業(yè)務(wù)邏輯中調(diào)用發(fā)送郵件的邏輯。這 樣用戶業(yè)務(wù)就依賴于郵件業(yè)務(wù)。如果以后改為短信激活，注冊用戶業(yè)務(wù)邏輯就必須修改為調(diào)用發(fā)送短信的邏輯。如果要注冊后給用戶加點積分，再加一段邏輯。經(jīng)過 多次修改，我們發(fā)現(xiàn)很簡單的注冊用戶業(yè)務(wù)已經(jīng)越來越復(fù)雜，越來越難以維護(hù)。相信很多開發(fā)者都會有類似痛苦的經(jīng)歷。

即使用戶業(yè)務(wù)實現(xiàn)中對其他業(yè)務(wù)是接口依賴，也避免不了業(yè)務(wù)變化帶來的依賴影響。怎么辦？解耦！將注冊用戶業(yè)務(wù)邏輯中注冊成功后的處理剝離出來。
再回頭看看”訂閱雜志”，如果沒有郵局，出版社就必須自己將雜志送達(dá)所有消費者。這種情形就和現(xiàn)在的注冊用戶業(yè)務(wù)一樣。我們發(fā)現(xiàn)問題了，在用戶業(yè)務(wù)和其他業(yè)務(wù)之間缺少了郵局所扮角色。
我們把郵局抽象成一個管理消息的地方，叫”消息管理器”。注冊用戶成功后發(fā)送一個消息給消息管理器，由消息管理器轉(zhuǎn)發(fā)該消息給需要處理的業(yè)務(wù)?，F(xiàn)在，用戶業(yè)務(wù)只依賴于消息管理器了，它再也不會為了注冊用戶成功后的其他處理而煩惱。

注冊用戶的改造就是借鑒了”訂閱雜志”這樣原始的模式。我們再進(jìn)一步抽象，用戶業(yè)務(wù)就是消息的”生產(chǎn)者”，它將消息發(fā)布到消息管理器。郵件業(yè)務(wù)就是 消息的”消費者”，它將收到的消息進(jìn)行處理。郵局可以訂閱很多種雜志，雜志都是通過某種編號來區(qū)分；消息管理器也可以管理多種消息，每種消息都會有一個 “主題”來區(qū)分，消費者都是通過主題來訂閱的。

發(fā)布-訂閱消息模式已經(jīng)呈現(xiàn)在我們面前，利用它可以產(chǎn)生更靈活、更松散耦合的系統(tǒng)。

MQ相關(guān)概念
1.消息(Message)

消息是MQ中最小的概念，本質(zhì)上就是一段數(shù)據(jù)，它能被一個或者多個應(yīng)用程序所理解，是應(yīng)用程序之間傳遞的信息載體。

2.隊列(Queue）

2.1本地隊列

本地隊列按照功能可劃分為初始化隊列，傳輸隊列，目標(biāo)隊列和死信隊列。

初始化隊列用作消息觸發(fā)功能。

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

目標(biāo)隊列是消息的目的地，可以長期存放消息。

如果消息不能送達(dá)目標(biāo)隊列，也不能再路由出去，則被自動放入死信隊列保存。

2.2別名隊列&遠(yuǎn)程隊列

只是一個隊列定義，用來指定遠(yuǎn)端隊列管理器的隊列。使用了遠(yuǎn)程隊列，程序就不需要知道目標(biāo)隊列的位置。

2.3模型隊列

模型隊列定義了一套本地隊列的屬性結(jié)合，一旦打開模型隊列，隊列管理器會按照這些屬性動態(tài)地創(chuàng)建出一個本地隊列。

3.隊列管理器(Queue Manager)

隊列管理器是一個負(fù)責(zé)向應(yīng)用程序提供消息服務(wù)的機(jī)構(gòu)，如果把隊列管理器比作數(shù)據(jù)庫，那么隊列就是其中一張表。

4.通道(Channel)

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

5.監(jiān)聽器(listner)

MQ產(chǎn)品的特性
可靠性傳輸

這個特點可以說是消息中間件的立足之本，對于應(yīng)用來說，只要成功把數(shù)據(jù)提交給消息中間件，那么關(guān)于數(shù)據(jù)可靠傳輸?shù)膯栴}就由消息中間件來負(fù)責(zé)。

不重復(fù)傳輸

不重復(fù)傳播也就是斷點續(xù)傳的功能，特別適合網(wǎng)絡(luò)不穩(wěn)定的環(huán)境，節(jié)約網(wǎng)絡(luò)資源。

異步性傳輸

異步性傳輸是指，接受信息雙方不必同時在線，具有脫機(jī)能力和安全性。

消息驅(qū)動

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

支持事務(wù)

應(yīng)用程序可以把一些數(shù)據(jù)更新組合成一個工作單元，這些更新通常是邏輯相關(guān)的，為了保障數(shù)據(jù)完整性，所有的更新必須同時成功或者同時失敗）。

常用MQ產(chǎn)品比較

ActiveMQ    Joram   HornetQ OpenMQ  MuleMQ  SonicMQ RabbitMQ    ZeroMQ

關(guān)注度 高 中 中 中 低 低 高 中
成熟度 成熟 比較成熟 比較成熟 比較成熟 新產(chǎn)品無成功案例 成熟 成熟 不成熟
所屬社區(qū)/公司 Apache OW2 Jboss Sun Mule Progress
社區(qū)活躍度 高 中 中 低 高 低 高 低
文檔 多 多 中 中 少 少 多 中
特點 功能齊全，被大量開源項目使用 在Linux平臺上直接調(diào)用操作系統(tǒng)的AIO，性能得到很大的提升 性能非常好，與MuleESB無縫整合 性能優(yōu)越的商業(yè)MQ 由于Erlang語言的并發(fā)能力，性能很好 低延時，高性能，最高43萬條消息每秒
授權(quán)方式 開源 開源 開源 開源 商業(yè) 商業(yè) 開源 開源
開發(fā)語言 Java Java Java Java Java Java Erlang C
支持的協(xié)議 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等
持久化 內(nèi)存、文件、數(shù)據(jù)庫 內(nèi)存、文件 內(nèi)存、文件 內(nèi)存、文件 內(nèi)存、文件 內(nèi)存、文件、數(shù)據(jù)庫 內(nèi)存、文件 在消息發(fā)送端保存
事務(wù) 支持 支持 支持 支持 支持 支持 不支持 不支持
集群 支持 支持 支持 支持 支持 支持 支持 不支持
負(fù)載均衡 支持 支持 支持 支持 支持 支持 支持 不支持
管理界面 一般
一般 無 一般 一般 好 無 無
部署方式 獨立、嵌入 獨立、嵌入 獨立、嵌入 獨立、嵌入 獨立 獨立 獨立 獨立
評價 成熟穩(wěn)定，開源首選 依賴容器，不適合跨語言調(diào)用 推出的時間不長，尚無使用案例，不適合跨語言調(diào)用 依賴容器，不適合跨語言調(diào)用 推出的時間不長，無成功案例，目前僅支持Java 成熟穩(wěn)定 Queue的數(shù)量大于50后，高并發(fā)下無法持續(xù)穩(wěn)定的提供服務(wù) 不支持事務(wù)、集群，并且消息不能在服務(wù)端持久化

MQ適用場景介紹
MQ消息隊列是應(yīng)運松偶合的概念而產(chǎn)生的，主要以隊列和發(fā)布訂閱為消息傳輸機(jī)制，以異步的方式將消息可靠的傳輸?shù)较M端的一種基礎(chǔ)產(chǎn)品。

它被廣泛的應(yīng)用與跨平臺、跨系統(tǒng)的分布式系統(tǒng)之間，為它們提供高效可靠的異步傳輸機(jī)制。

消息通道（Message Channel）
使用MQ將彼此協(xié)作的客戶端和服務(wù)端連接起來，使他們可以交換消息。

如客戶端與服務(wù)端需要安全可靠的交互，可以將一個MQ的隊列作為安全通道，是客戶端與服務(wù)端能夠安全高效的進(jìn)行異步通訊。

消息總線（Message Bus）
對于由許多獨立開發(fā)的服務(wù)組成的分布式系統(tǒng)，倘若要將它們組成一個完整的系統(tǒng)，這些服務(wù)必須能夠可靠地交互，同時，為了系統(tǒng)的健壯性，

每個服務(wù)之間又不能產(chǎn)生過分緊密的依賴關(guān)系，這樣就可以通過消息總線將不同的服務(wù)連接起來，允許它們異步的傳遞數(shù)據(jù)。

消息路由（Message Router）
通過消息路由，可以將發(fā)送到MQ指定隊列的消息根據(jù)規(guī)則路由到不同的隊列。

此外，JMS規(guī)范還支持通過selector條件，對消息進(jìn)行過濾，可以用多個消費者消費同一個隊列的消息，每個消費者只消費自己感興趣的消息。

發(fā)布/訂閱（Publicsher/Subscriber）
發(fā)布/訂閱模式用于一對多的通訊，當(dāng)消息發(fā)布者向一個主題（Topic）發(fā)送一條消息后，該主題的所有訂閱者都會收到這條消息。