張逸凡　于志安

摘要：高級(jí)消息隊(duì)列協(xié)議是針對(duì)面向消息中間件的開放式標(biāo)準(zhǔn)的應(yīng)用層協(xié)議規(guī)范，它面向消息并以隊(duì)列存儲(chǔ)，支持點(diǎn)對(duì)點(diǎn)及pub-sub的路由，具有可靠性和安全性。作為線路層協(xié)議，高級(jí)消息隊(duì)列協(xié)議允許來自不同用戶的消息生產(chǎn)者和消費(fèi)者實(shí)現(xiàn)真正的互操作擴(kuò)展，就如同SMTP、HTTP、FTP等協(xié)議采用的方式一樣。該文以高級(jí)消息隊(duì)列協(xié)議的消息機(jī)制為基礎(chǔ)，探索該協(xié)議于流式信息（或文件）傳輸?shù)目尚行?，和?duì)其拓展的展望。

關(guān)鍵詞：AMQP；消息隊(duì)列；協(xié)議；消息中間件；消息路由；協(xié)議緩沖

中圖分類號(hào)：TP393 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1009-3044（2014）01-0047-04

高級(jí)消息隊(duì)列協(xié)議（Advanced Message Queuing Protocol），以下簡稱AMQP協(xié)議，是一個(gè)異步消息傳遞所使用的應(yīng)用層協(xié)議規(guī)范。它的特點(diǎn)是面向消息，存儲(chǔ)隊(duì)列，支持點(diǎn)對(duì)點(diǎn)及pub-sub的路由，具有可靠性和安全性[1][3]。

作為線路層協(xié)議，AMQP允許來自不同用戶的消息生產(chǎn)者和消費(fèi)者實(shí)現(xiàn)真正的互操作擴(kuò)展，就如同SMTP、HTTP、FTP等協(xié)議采用的方式一樣。而此前對(duì)于消息中間件的標(biāo)準(zhǔn)化努力則集中在API層面上（比如JMS），且沒有提供互操作性的途徑。不同于JMS的僅僅定義API，AMQP是一個(gè)線路層的協(xié)議——它描述了通過網(wǎng)絡(luò)傳輸?shù)淖止?jié)流的數(shù)據(jù)格式。因此，遵從這個(gè)協(xié)議的任何語言編寫的工具均可以操作AMQP消息[4]。

當(dāng)前關(guān)于AMQP的實(shí)現(xiàn)對(duì)象大都是企業(yè)級(jí)的內(nèi)部消息應(yīng)用（如JP Morgan）或是一些封閉系統(tǒng)的中間消息層（如red hat），它們主要面向的都是以輕量文本消息為介質(zhì)的對(duì)象（可能也是出于穩(wěn)定性的考慮）。但在大數(shù)據(jù)應(yīng)用背景下，使用消息系統(tǒng)進(jìn)行大流量的傳輸過程存在數(shù)據(jù)單元離散化產(chǎn)生的的傳輸性能瓶頸、并發(fā)輸出和消息數(shù)據(jù)承載格式受限等問題，該文試圖與AMQP結(jié)合使用Google的Protocol buffer，通過其提供的先進(jìn)的可編程編解碼方式來改善其傳輸性能并解決相應(yīng)的問題。

1 AMQP協(xié)議

1.1 起源

AMQP由JP Morgan自2004年中期至2006年中期獨(dú)自開發(fā)。IMatix公司也開發(fā)了C/C++和java的實(shí)現(xiàn)。兩家公司將這個(gè)協(xié)議文檔化并且規(guī)范了互操作性，發(fā)起成立專門的工作組，成員有JP Morgan Chase、Red Hat、 Cisco Systems、 TWIST、 IONA、 iMatix等。AMQP作為規(guī)范發(fā)布于2006年1月20日，工作組在設(shè)計(jì)時(shí)考慮了性能和可交互性，為基于隊(duì)列的消息機(jī)制訂立了一個(gè)協(xié)議和模型。AMQP協(xié)議的目標(biāo)是普及消息中間件并跨越不同技術(shù)門檻，在各種語言或者各種操作系統(tǒng)之間提供真正的可交互性。出現(xiàn)了許多基于AMQP的軟件商及其產(chǎn)品，表1列出了部份AMQP的軟件商和其產(chǎn)品，具有很好的交互性，比如，重載了AMQP的JMS API能夠很容易地與.net客戶端以及任何其他語言或其他借助AMQP通訊的平臺(tái)進(jìn)行交互。

1.2協(xié)議概念結(jié)構(gòu)

AMQP協(xié)議由是關(guān)鍵實(shí)體和語義表示的邏輯框架，主要有Broker（服務(wù)器）地址、用戶信息、Exchange（信息交換器）、Exchange-Type（交換器類型）、Queue（消息隊(duì)列）、Routing-Key（路由關(guān)鍵詞）和Message（消息體）等。其中：

1） Broker是指AMQP客戶端所要連接的服務(wù)器實(shí)例，是消息協(xié)議的核心部分。

2） 用戶信息包含了用戶名、密碼等驗(yàn)證信息，來通過AMQP的用戶認(rèn)證機(jī)制并接入Broker，但是也可以不經(jīng)認(rèn)證直接接入。

3） Exchange是消息送達(dá)的實(shí)體，在broker中扮演消息路由結(jié)點(diǎn)的角色，除了在一對(duì)一這樣的最基本的情況外，是消息流的必經(jīng)之地。

4） Queue是接受消息的實(shí)體，具有名稱和屬性，但沒有類型?？蛻舳丝梢杂嗛嗞?duì)列以便讓Broker遞送某個(gè)消息隊(duì)列的內(nèi)容到該客戶端。另外，客戶端也可自動(dòng)到隊(duì)列取他所感興趣的消息。消息確保以自己被送往隊(duì)列時(shí)順序分發(fā)，但在進(jìn)行某些重新路由的操作如失效處理時(shí)，其順序則不能保證。（注：AMQP 1.0中，隊(duì)列將替代交換器。）

5） Routing-Key位于消息頭，它的使用與否取決于交換器的類型。它的作用是作為用來與交換器匹配的關(guān)鍵詞。

6） Exchange-Type定義了交換器的工作模式，一般分為Direct、Fan-Out、Topic三種方式。

1.3 消息路由模型（定義文字不清晰）

理解消息如何傳遞到隊(duì)列的關(guān)鍵在于交換器的類型與路由關(guān)鍵詞之間的關(guān)系。當(dāng)一個(gè)消息的路由關(guān)鍵詞與綁定中的模式匹配時(shí)，交換器會(huì)把該消息的拷貝送達(dá)隊(duì)列。如何進(jìn)行匹配僅依賴于交換器的類型：

① Direct型：消息的路由關(guān)鍵詞與綁定相同。

② Fan-Out型：總是匹配，即使綁定無關(guān)鍵詞。

③ Topic型：匹配路由關(guān)鍵詞屬性，字符串的各個(gè)部分以'.'分隔?？砂瑑蓚€(gè)特殊字符：'*'表示單個(gè)任意詞，'#'表示0個(gè)或多個(gè)詞，例如 *.stock.# 匹配usd.stock和eur.stock.db，但不匹配stock.nasdaq。

根據(jù)以上元素組合可以組成一些典型的消息路由模型。

靈活地組合AMQP結(jié)構(gòu)就可以很方便的在跨平臺(tái)和跨語言的基礎(chǔ)上搭建“消息廣播”，“即時(shí)通信”，“電子郵件”等這類常見消息應(yīng)用的架構(gòu)，極大地簡化了工作量。當(dāng)然，這也正是該開源協(xié)議的設(shè)計(jì)初衷。

2 基于AMQP協(xié)議的大數(shù)據(jù)傳輸問題及原因

當(dāng)AMQP協(xié)議用于互聯(lián)網(wǎng)應(yīng)用時(shí)，就會(huì)遭遇到大數(shù)據(jù)傳輸問題和不同的數(shù)據(jù)承載格式。以常用的電郵系統(tǒng)為例，現(xiàn)代電子郵件已經(jīng)不再僅僅是一組字符串的信息段的組合了，可能會(huì)包括圖片或是網(wǎng)頁剪輯，尤其是大容量附件；另外，組合使用多種數(shù)據(jù)格式也非常普遍，圖片、視頻流和音頻流已是主流應(yīng)用的標(biāo)準(zhǔn)配置。

2.1存在問題（沒點(diǎn)出問題，分析部份應(yīng)作為2.2中，作為分析的一部分）

AMQP原本設(shè)計(jì)的目上開看，是為了實(shí)現(xiàn)一個(gè)通用的標(biāo)準(zhǔn)讓網(wǎng)絡(luò)具有消息中間件的能力，從而降低企業(yè)和系統(tǒng)集成上的開銷。其使用對(duì)象主要在于系統(tǒng)級(jí)別用戶，但對(duì)于單個(gè)系統(tǒng)節(jié)點(diǎn)或是企業(yè)內(nèi)部節(jié)點(diǎn)網(wǎng)絡(luò)而言，還遠(yuǎn)遠(yuǎn)達(dá)不到AMQP所提供的性能支持上限。所以，將AMQP的實(shí)現(xiàn)應(yīng)用于較大信息量的交換也是有一定前景的，但這還需要進(jìn)行進(jìn)一步的實(shí)踐。這里以100k文本數(shù)據(jù)量為例，模擬分段傳輸100～1000個(gè)該數(shù)據(jù)量的數(shù)據(jù)段并計(jì)算時(shí)間。

圖5 數(shù)據(jù)傳輸測試統(tǒng)計(jì)

由圖5可以看出，基本上時(shí)間和數(shù)據(jù)量基本上是以線性的關(guān)系增長的。共100m文件傳輸所花的時(shí)間也僅稍高于本地硬盤數(shù)據(jù)傳輸?shù)拈_銷，所以在分開請求數(shù)據(jù)的代價(jià)比較小。

2.2 主要原因

可見一般情況下AMQP的主要瓶頸在于輸入/輸出端的響應(yīng)時(shí)間。那是否是說這樣的話那分包數(shù)越小對(duì)性能就越好呢？當(dāng)然不是，這僅僅是理論情況。在實(shí)際運(yùn)用中，數(shù)據(jù)的完整性也是需要相當(dāng)考量的問題。若是一個(gè)近幾百兆的數(shù)據(jù)段在傳輸?shù)倪^程中發(fā)生了中斷或是缺失這樣的情況，數(shù)據(jù)分包自然就不是越少越好了。

需要在兩者之間找到一種平衡，接下來會(huì)用一種數(shù)據(jù)流式化的方法來解決這一問題。

3 一種基于AMQP協(xié)議的大數(shù)據(jù)傳輸方式

3.1流式編碼信息方式替換文本消息的傳輸

基于對(duì)標(biāo)準(zhǔn)文本信息流式化編碼的設(shè)計(jì)，這里引入了Google的Protocol Buffers技術(shù)來將先前的文本測試數(shù)據(jù)序列化封裝，通過設(shè)計(jì)流量測試用例程序來模擬流式文件的傳輸過程并于純文本用例進(jìn)行性能對(duì)比。

[import "common.header.proto"；

package amqp；

message test

{ required common.header header = 1； //信息頭擴(kuò)展，這里暫不定義

required int32 tid = 2； //信息編號(hào)

required int32 length = 3； //數(shù)據(jù)長度

required bool end_flag = 4； //是否結(jié)尾的標(biāo)志位

repeated bytes data = 5； //數(shù)據(jù)段

}]

例1 amqp.test.proto文件實(shí)例

Protocol Buffers（Protobuf，官方譯名“協(xié)議緩沖”）是Google公司開發(fā)的一種數(shù)據(jù)描述語言，類似于XML能夠?qū)⒔Y(jié)構(gòu)化數(shù)據(jù)序列化，可用于數(shù)據(jù)存儲(chǔ)、通信協(xié)議等方面?，F(xiàn)階段支持C++、JAVA、Python等三種編程語言。它的工作方式是通過編輯.proto文件來定義需要序列化信息的格式，每個(gè)buffer消息是一個(gè)邏輯記錄，包括一系列的名稱和值的組合甚至是架構(gòu)子數(shù)據(jù)結(jié)構(gòu)。Protobuf有如XML，不過它更小、更快、也更簡單。你可以定義自己的數(shù)據(jù)結(jié)構(gòu)，然后使用代碼生成器生成的代碼來讀寫這個(gè)數(shù)據(jù)結(jié)構(gòu)。

針對(duì)數(shù)據(jù)的傳輸，編譯Protobuf定義文件amqp.test.proto生成的對(duì)應(yīng)數(shù)據(jù)類功能代碼。其中對(duì)于少量數(shù)據(jù)情形，會(huì)將多個(gè)數(shù)據(jù)包通過一個(gè)數(shù)據(jù)結(jié)構(gòu)（見例1. repeated聲明段落）來進(jìn)行預(yù)先并包。較大數(shù)據(jù)則是拆分為多個(gè)字節(jié)段，并提供了數(shù)據(jù)編號(hào)和數(shù)據(jù)長度等元信息，以保證數(shù)據(jù)校驗(yàn)。

根據(jù)該數(shù)據(jù)類提供的高效序列化和反序列化方法來對(duì)測試用例程序的消息發(fā)送和接收部分進(jìn)行高層封裝來提供編碼支持。測試數(shù)據(jù)依然是以100k數(shù)據(jù)流量來分別用100～1000條數(shù)據(jù)發(fā)送，通過多次試驗(yàn)獲得平均性能。結(jié)合標(biāo)準(zhǔn)用例來比較編碼后的傳輸效率。

圖6 數(shù)據(jù)傳輸對(duì)比

在檢查效率提升的同時(shí)，選取較大數(shù)據(jù)源（100m）來測試傳輸方式的數(shù)據(jù)完整性，多次試驗(yàn)的結(jié)果依然是100%。

3.2 應(yīng)用可行性

本文中解決的問題主要為長段數(shù)據(jù)的分包和解包問題，消息路由模型的選擇和流式數(shù)據(jù)基礎(chǔ)處理，是常規(guī)情況下消息中間件都需要處理在大數(shù)據(jù)流量情況下需要解決的主要問題。而在實(shí)際應(yīng)用中，特別是互聯(lián)網(wǎng)應(yīng)用，需要考慮的問題會(huì)更多。比如由于網(wǎng)絡(luò)問題而導(dǎo)致部分?jǐn)?shù)據(jù)丟包、缺包甚至于斷線重連的問題，這就需要對(duì)數(shù)據(jù)校驗(yàn)、請求應(yīng)答和傳輸恢復(fù)等機(jī)制這些方面多加以考慮。再比如說服務(wù)器端的穩(wěn)定性，由于AMQP對(duì)于數(shù)據(jù)的持久性還沒有特別好的解決（具有“durable”設(shè)置但還遠(yuǎn)遠(yuǎn)不夠），所以需要把大量的數(shù)據(jù)轉(zhuǎn)存管理，并且一旦出現(xiàn)異常，對(duì)于數(shù)據(jù)的保存和恢復(fù)也應(yīng)該要有相應(yīng)的途徑。

4 結(jié)束語

相對(duì)于HTTP、FTP和MMS這樣的常用數(shù)據(jù)協(xié)議，作為新技術(shù)AMQP顯得并不成熟并且認(rèn)識(shí)度偏窄，但是它的前景已然可觀，該協(xié)議具有較高的集成度，性能也不輸（現(xiàn)今瓶頸都在硬件部分），設(shè)計(jì)規(guī)范，易于使用，部分實(shí)現(xiàn)已經(jīng)成熟使用，發(fā)展也十分迅速，相信，在未來幾年里，AMQP會(huì)得到更加廣泛的應(yīng)用。

參考文獻(xiàn)：

[1] AMQP Working Group. Advanced message queuing protocol， 2010.http：//www.amqp.org.

[2] O'Hara， J. "Toward a commodity enterprise middleware".Acm Queue 5：48–55， 2007.doi： 10.1145/1255421.1255424.

[3] Vinoski， S. "Advanced Message Queuing Protocol". Internet Computing， IEEE， 10（6）： 87-89， 2006.doi：10.1109/MIC.2006.116.

[4] Appel， Stefan （TU Darmstadt， Germany）； Sachs， Kai； Buchmann， Alejandro. "Towards benchmarking of AMQP". Proceedings of the 4th ACM International Conference on Distributed Event-Based Systems， DEBS 2010： 9-100， 2010.doi：10.1145/1827418.1827438.

[5] Xiong， Xuandong； Fu， Jiandan. "Active Status Certificate Publish and Subscribe Based on AMQP". Computational and Information Sciences （ICCIS）， 2011 International Conference on： 725-728， Oct， 2011. doi： 10.1109/ICCIS.2011.63.