RabbitMQ 小消息確認(rèn)機(jī)制優(yōu)化①

徐 震, 焦文彬

1(中國科學(xué)院 計(jì)算機(jī)網(wǎng)絡(luò)信息中心,北京 100190)

2(中國科學(xué)院大學(xué),北京 100049)

RabbitMQ是開源的基于Erlang的高效部署分布式消息隊(duì)列,實(shí)現(xiàn)了AMQP協(xié)議,具有良好的可靠性、穩(wěn)定性,可運(yùn)行在多種操作系統(tǒng),便于集群運(yùn)行[1-6].RabbitMQ支持多種編程語言的客戶端,可以通過安裝插件擴(kuò)展功能. RabbitMQ可以解耦應(yīng)用程序,將不同語言開發(fā)的程序粘合在一起,在完全不同的應(yīng)用之間共享數(shù)據(jù).

Erlang采用輕量級(jí)并發(fā)模型,用于高并發(fā)、分布式“軟實(shí)時(shí)系統(tǒng)”編程,支持運(yùn)行系統(tǒng)中的軟件升級(jí)[7].Erlang程序簡(jiǎn)短緊湊,采用函數(shù)式編程,自動(dòng)存儲(chǔ)管理.Erlang進(jìn)程不共享內(nèi)存,進(jìn)程間通信通過消息傳遞進(jìn)行.

RabbitMQ投遞消息的速度受軟硬件配置影響. 硬件方面有： 處理器、內(nèi)存、磁盤、網(wǎng)絡(luò)配置等; 軟件方面有： 消息持久化機(jī)制、消息確認(rèn)機(jī)制、交換器類型等. 要以高速度向消費(fèi)者投遞消息,應(yīng)盡可能保持隊(duì)列為空.

對(duì)RabbitMQ進(jìn)行優(yōu)化有較多方法. 如對(duì)生產(chǎn)者確認(rèn)機(jī)制的優(yōu)化： 直接建立channel與消息存儲(chǔ)之間的聯(lián)系,減少插入、刪除、消息傳遞等操作,可以大幅降低處理時(shí)間[8]. 還可以優(yōu)化topic路由匹配算法; 批量發(fā)送消息; 優(yōu)化消息持久化機(jī)制; 開啟Erlang HiPE編譯選項(xiàng); 使用位運(yùn)算等.

生產(chǎn)者發(fā)送一條消息到broker,消息可能被n個(gè)消費(fèi)者接收. 同時(shí)啟用生產(chǎn)者確認(rèn)與消費(fèi)者確認(rèn),生產(chǎn)者仍無法獲知n個(gè)消費(fèi)者是否全部接收到消息. 本文對(duì)小消息情況下RabbitMQ的確認(rèn)機(jī)制進(jìn)行優(yōu)化,在broker收到n個(gè)消費(fèi)者的確認(rèn)消息后,向生產(chǎn)者發(fā)送確認(rèn)消息. 生產(chǎn)者收到確認(rèn)消息則表明消費(fèi)者已成功接收到消息. 若消息丟失,由生產(chǎn)者負(fù)責(zé)重發(fā)消息. 對(duì)不同生產(chǎn)者、消費(fèi)者、隊(duì)列數(shù)量的情況進(jìn)行測(cè)試,分析比較優(yōu)化前與優(yōu)化后的持久化小消息發(fā)送速率.

1 RabbitMQ架構(gòu)與相關(guān)模塊簡(jiǎn)介

1.1 RabbitMQ架構(gòu)

如圖1所示,生產(chǎn)者發(fā)送消息到交換器,隊(duì)列通過路由鍵綁定到交換器,根據(jù)交換器類型與路由鍵將消息路由到隊(duì)列,消費(fèi)者從隊(duì)列接收消息. 常用的交換器類型有direct、fanout和topic. 對(duì)于direct交換器,如果路由鍵匹配,消息就被投入相應(yīng)的隊(duì)列; fanout交換器將收到的消息廣播到綁定的隊(duì)列; topic交換器對(duì)路由鍵進(jìn)行模式匹配,消息被路由到匹配的隊(duì)列. 消費(fèi)者通過basic.consume命令自動(dòng)從隊(duì)列獲取下一條消息;通過basic.get命令獲取單條消息. 隊(duì)列具有多個(gè)消費(fèi)者時(shí),采用round-robin方式向消費(fèi)者發(fā)送消息. broker是消息隊(duì)列服務(wù)器實(shí)體,一個(gè)broker中可以有多個(gè)虛擬主機(jī).

1.2 相關(guān)模塊功能

1) channel接收reader解析的來自客戶端的協(xié)議幀; 使用writer向客戶端發(fā)送幀; 路由消息給隊(duì)列進(jìn)程;處理AMQP方法; 發(fā)出AMQP命令. 一條TCP連接中可以有多個(gè)channel.

2) 支持隊(duì)列(backing queue,BQ),一般情況下默認(rèn)為rabbit_variable_queue. 隊(duì)列進(jìn)程使用BQ實(shí)現(xiàn)隊(duì)列功能. 隊(duì)列中消息具有4種狀態(tài)： alpha、beta、gamma、delta. 持久化消息只可能處于alpha、gamma、delta三種狀態(tài)之一. BQ具有5個(gè)內(nèi)部隊(duì)列： q1、q2、q3、q4、delta. q1和q4中只有alpha狀態(tài)的消息; q2和q3包含beta和gamma狀態(tài)的消息; delta隊(duì)列不在內(nèi)存中,只有delta狀態(tài)的消息.

3) 隊(duì)列索引(queue index)用于在磁盤上記錄隊(duì)列中消息的順序. 每個(gè)隊(duì)列有一個(gè)隊(duì)列索引. 消息依次被發(fā)布、投遞、確認(rèn). 發(fā)布記錄包括消息ID、消息在隊(duì)列中的序列號(hào)等內(nèi)容. 發(fā)布記錄也可能包括完整的消息. 投遞和確認(rèn)記錄只包括消息在隊(duì)列中的序列號(hào). 隊(duì)列索引使用日志文件(journal)避免過多磁盤尋址. 日志文件具有固定的長度,默認(rèn)為32 768,由queue_index_max_journal_entries參數(shù)配置.

4) 消息存儲(chǔ)(message store)用于將消息寫入磁盤或?qū)⑾拇疟P加載到內(nèi)存. 存儲(chǔ)的消息是引用計(jì)數(shù)的,ID相同的消息多次寫入時(shí)只會(huì)存儲(chǔ)一次.

圖1 RabbitMQ架構(gòu)圖

1.3 小消息嵌入隊(duì)列索引

RabbitMQ 3.5.0版本引入小消息嵌入隊(duì)列索引. 小于queue_index_embed_msgs_below參數(shù)值的消息屬于小消息,該參數(shù)默認(rèn)值為4096 bytes. 小消息的持久化操作直接在隊(duì)列進(jìn)程中進(jìn)行,不使用消息存儲(chǔ),只需要寫一次磁盤,可以減少I/O和內(nèi)存消耗,提高10%左右的性能[9].

如果小消息被一個(gè)交換器路由到多個(gè)隊(duì)列,這條消息需要被寫入多個(gè)隊(duì)列索引; 若使用消息存儲(chǔ),則只需要寫一次. 從磁盤讀取消息時(shí),每個(gè)隊(duì)列索引需要在內(nèi)存中保持至少1個(gè)段文件. 段文件包含16 384條消息記錄. 因此queue_index_embed_msgs_below參數(shù)的少量增加會(huì)導(dǎo)致大量的內(nèi)存使用[10].

2 RabbitMQ消息確認(rèn)過程分析

如圖2所示,生產(chǎn)者確認(rèn)是異步的,生產(chǎn)者發(fā)送消息到broker,可以在等待確認(rèn)的同時(shí)發(fā)送下一條. 為了在broker重啟或崩潰時(shí)不丟失消息,消息投遞給消費(fèi)者前需要進(jìn)行持久化,消息寫入磁盤后向生產(chǎn)者發(fā)送確認(rèn)消息. 消費(fèi)者收到消息后必須進(jìn)行確認(rèn),可以發(fā)送

basic.ack命令進(jìn)行顯示確認(rèn),也可以使用自動(dòng)確認(rèn). 若使用自動(dòng)確認(rèn),消費(fèi)者接收到消息,即視其確認(rèn)了消息.broker收到消費(fèi)者發(fā)送的確認(rèn)消息,將確認(rèn)記錄追加到隊(duì)列索引的日志文件.

圖2 消息確認(rèn)過程與消息持久化關(guān)系圖

開啟生產(chǎn)者確認(rèn)與消費(fèi)者確認(rèn),持久化小消息在生產(chǎn)者、消費(fèi)者、RabbitMQ相關(guān)模塊間的傳遞過程如圖 3所示. 1-6： 生產(chǎn)者發(fā)送消息到消費(fèi)者; 7-10： 消費(fèi)者確認(rèn)相關(guān)過程; 11-14： 生產(chǎn)者確認(rèn)相關(guān)過程.

圖3 小消息確認(rèn)過程圖

2.1 生產(chǎn)者確認(rèn)過程分析

生產(chǎn)者確認(rèn)過程會(huì)依次在channel、隊(duì)列進(jìn)程、隊(duì)列索引、BQ處記錄生產(chǎn)者確認(rèn)相關(guān)信息. 消息寫入磁盤后,已確認(rèn)的消息ID從隊(duì)列索引依次傳遞給BQ、隊(duì)列進(jìn)程、channel,各處均會(huì)將已確認(rèn)記錄刪除.

channel收到生產(chǎn)者發(fā)送的消息,為消息分配一個(gè)唯一的序列號(hào),組裝#delivery,獲取需要投遞的隊(duì)列記錄列表Qs,將#delivery投遞到Qs中的隊(duì)列. channel使用dtree記錄消息被投遞到哪些隊(duì)列,格式為： {消息在channel中的序列號(hào),隊(duì)列進(jìn)程pid列表,交換器名稱}.若channel將消息投遞到m個(gè)隊(duì)列,channel收到相應(yīng)的m個(gè)隊(duì)列發(fā)送的確認(rèn)消息才會(huì)向生產(chǎn)者發(fā)送確認(rèn)消息.

隊(duì)列進(jìn)程收到消息,判斷隊(duì)列的消費(fèi)者是否滿足消息投遞條件. 若有消費(fèi)者滿足投遞條件且消息隊(duì)列為空,則消息不會(huì)進(jìn)入隊(duì)列,而是直接投遞給消費(fèi)者端channel. 需要組裝消息狀態(tài)(message status). 將包含小消息的發(fā)布記錄與只包括消息在隊(duì)列中序列號(hào)的投遞記錄追加到隊(duì)列索引的日志文件.

若沒有消費(fèi)者滿足投遞條件或消息隊(duì)列非空,則將消息進(jìn)隊(duì). 需要組裝消息狀態(tài). 將發(fā)布記錄追加到隊(duì)列索引的日志文件. 將消息狀態(tài)加入消息隊(duì)列. 從消息隊(duì)列中取消息時(shí),若消息隊(duì)列非空且有消費(fèi)者滿足消息投遞條件,則將消息從消息隊(duì)列中移除. 將投遞記錄追加到隊(duì)列索引的日志文件. 將取出的消息投遞給消費(fèi)者端channel.

隊(duì)列進(jìn)程收到生產(chǎn)者端channel投遞的消息,使用gb_trees記錄未確認(rèn)的消息ID、發(fā)送消息的channel和該消息在channel中的序列號(hào),格式為： {消息ID,{channel pid,消息在channel中的序列號(hào)}}.

在發(fā)布記錄寫入日志文件前,隊(duì)列索引使用gb_sets記錄未確認(rèn)的消息ID. 隊(duì)列索引的日志文件可能在兩種情況下寫入磁盤.

1) 隊(duì)列進(jìn)程設(shè)置同步定時(shí)器,每200毫秒向自身發(fā)送sync_timeout消息. 隊(duì)列進(jìn)程收到消息后,對(duì)隊(duì)列索引的日志文件執(zhí)行sync操作.

2) 當(dāng)日志文件中記錄數(shù)目達(dá)到一定數(shù)量時(shí),將內(nèi)存中預(yù)分割的日志文件寫入段文件.

消息持久化操作完成后,BQ使用gb_sets記錄未確認(rèn)的消息ID.

2.2 消費(fèi)者確認(rèn)過程分析

消費(fèi)者確認(rèn)過程會(huì)依次在BQ、隊(duì)列進(jìn)程、channel處記錄消費(fèi)者確認(rèn)相關(guān)信息. 收到消費(fèi)者發(fā)送的確認(rèn)消息后,會(huì)按照相反的順序從未確認(rèn)記錄中刪除已確認(rèn)記錄,最終將包括消息在隊(duì)列中序列號(hào)的確認(rèn)記錄追加到隊(duì)列索引的日志文件.

消息到達(dá)隊(duì)列進(jìn)程直接投遞給消費(fèi)者端channel時(shí)或從消息隊(duì)列中取消息時(shí),會(huì)在BQ相應(yīng)的gb_trees中添加未確認(rèn)記錄,格式為： {消息在隊(duì)列中的序列號(hào),消息狀態(tài)}.

隊(duì)列進(jìn)程將消息投遞給channel,在Erlang queue中添加未確認(rèn)記錄,格式為： {消息在隊(duì)列中的序列號(hào),消費(fèi)者標(biāo)簽}.

channel使用writer將消息投遞給消費(fèi)者,在Erlang queue中添加未確認(rèn)記錄,格式為： {投遞標(biāo)簽,消費(fèi)者標(biāo)簽,{隊(duì)列進(jìn)程pid,消息在隊(duì)列中的序列號(hào)}}. 收到消費(fèi)者發(fā)送的確認(rèn)消息后,channel根據(jù)確認(rèn)消息中的投遞標(biāo)簽與multiple字段從未確認(rèn)記錄中獲取已確認(rèn)記錄,將已確認(rèn)的消息序列號(hào)發(fā)送給相應(yīng)的隊(duì)列進(jìn)程.

2.3 對(duì)性能的影響

生產(chǎn)者確認(rèn)與消費(fèi)者確認(rèn)過程涉及較多dtree、gb_trees、gb_sets和Erlang queue操作,包括插入、刪除、查找、集合運(yùn)算等. 隊(duì)列索引的日志文件會(huì)定時(shí)地或在記錄達(dá)到一定數(shù)量時(shí)寫入磁盤,對(duì)性能影響較大.

使用RabbitMQ 2.8.1進(jìn)行簡(jiǎn)單測(cè)試,CPU為雙Xeon E5530,RAM為40GB,Erlang R15B,開啟HiPE,1個(gè)生產(chǎn)者,1個(gè)消費(fèi)者[11]. 不使用生產(chǎn)者確認(rèn)與消費(fèi)者確認(rèn),不進(jìn)行消息持久化,消息發(fā)送速率為： 44824 msg/s;開啟消費(fèi)者確認(rèn)后： 32005 msg/s; 接著開啟生產(chǎn)者確認(rèn)：26103 msg/s; 在此基礎(chǔ)上對(duì)消息進(jìn)行持久化： 4725 msg/s[12].可見消息確認(rèn)機(jī)制對(duì)消息發(fā)送速率有一定影響,消息持久化機(jī)制對(duì)消息發(fā)送速率有較大影響.

3 優(yōu)化方法

3.1 小消息確認(rèn)機(jī)制的優(yōu)化

如圖4所示,優(yōu)化后持久化與非持久化小消息的確認(rèn)過程是相同的. 需要將生產(chǎn)者確認(rèn)過程與消費(fèi)者確認(rèn)過程銜接起來. 生產(chǎn)者發(fā)送消息到broker,消息投遞給消費(fèi)者前,不進(jìn)行消息持久化操作. 不會(huì)向日志文件追加記錄,不寫段文件; 不會(huì)設(shè)置同步定時(shí)器,不執(zhí)行代價(jià)較大的sync操作. 隊(duì)列索引與BQ不記錄未確認(rèn)的消息ID. 消費(fèi)者收到消息后,向broker發(fā)送確認(rèn)消息. broker收到消費(fèi)者確認(rèn)消息,向生產(chǎn)者發(fā)送確認(rèn)消息. 若消費(fèi)者沒有收到消息,生產(chǎn)者不會(huì)收到確認(rèn)消息,此時(shí)由生產(chǎn)者重發(fā)該消息. 該方法保證了在生產(chǎn)者收到確認(rèn)消息時(shí)消費(fèi)者已成功接收到消息.

圖4 優(yōu)化后小消息確認(rèn)過程圖

1) 小消息到達(dá)隊(duì)列進(jìn)程,隊(duì)列進(jìn)程需要記錄生產(chǎn)者確認(rèn)相關(guān)信息. 需要修改隊(duì)列進(jìn)程模塊的send_or_record_confirms/2函數(shù). SenderPid是發(fā)送消息給隊(duì)列進(jìn)程的channel pid,MsgSeqNo是消息在channel中的序列號(hào),MTC用于記錄未確認(rèn)消息ID對(duì)應(yīng)的{SenderPid,MsgSeqNo}. 添加未確認(rèn)記錄后,更新隊(duì)列進(jìn)程狀態(tài).

2) 隊(duì)列進(jìn)程在消費(fèi)者確認(rèn)過程結(jié)束后,向生產(chǎn)者端channel發(fā)送確認(rèn)消息. 需要修改隊(duì)列進(jìn)程模塊的ack/3函數(shù). MsgIds是已確認(rèn)的消息ID列表. 需要獲取MsgIds對(duì)應(yīng)的channel pid和消息在channel中的序列號(hào),將包含消息在channel中序列號(hào)的確認(rèn)消息發(fā)送給相應(yīng)的channel. 更新隊(duì)列進(jìn)程狀態(tài).

3.2 繼續(xù)優(yōu)化消費(fèi)者確認(rèn)過程

可以在上述優(yōu)化的基礎(chǔ)上減少消費(fèi)者確認(rèn)過程中的插入、刪除等操作,提高性能,減少內(nèi)存使用. BQ和隊(duì)列進(jìn)程不記錄消費(fèi)者確認(rèn)相關(guān)消息,消費(fèi)者端channel記錄： {消息投遞標(biāo)簽,消費(fèi)者標(biāo)簽,{隊(duì)列進(jìn)程pid,消息ID}}.

1) 隊(duì)列進(jìn)程向channel投遞消息,格式為：{deliver,ConsumerTag,AckRequired,Msg}. ConsumerTag是消費(fèi)者標(biāo)簽,AckRequired取值為true或false. Msg類型為 rabbit_amqqueue：qmsg(),格式為： {隊(duì)列名稱,隊(duì)列進(jìn)程pid,消息在隊(duì)列中的序列號(hào),Redelivered,Message}.Redelivered取值為true或false,Message類型為#basic_message. 使用模式匹配從Message中提取消息ID. 需要修改channel模塊的record_sent/4函數(shù).

2) 消費(fèi)者端channel向隊(duì)列進(jìn)程發(fā)送的消息中包括已確認(rèn)的消息ID列表MsgIds. 隊(duì)列進(jìn)程收到確認(rèn)消息,向生產(chǎn)者端channel發(fā)送相應(yīng)的確認(rèn)消息. 更新隊(duì)列進(jìn)程狀態(tài). 需要修改隊(duì)列進(jìn)程模塊的handle_cast/2函數(shù).

4 性能測(cè)試

4.1 測(cè)試環(huán)境與方法

生產(chǎn)者、消費(fèi)者、RabbitMQ在同一臺(tái)機(jī)器上. 開啟生產(chǎn)者確認(rèn)與消費(fèi)者確認(rèn). 持久化小消息,消息大小為1500 bytes. 性能測(cè)試工具為PerfTest. 測(cè)試環(huán)境配置如表1所示.

表1 性能測(cè)試環(huán)境配置表

在1個(gè)虛擬主機(jī)中啟動(dòng)不同數(shù)量的持久化隊(duì)列,每個(gè)隊(duì)列有2個(gè)生產(chǎn)者、3個(gè)消費(fèi)者,每個(gè)生產(chǎn)者連接中有2個(gè)channel,每個(gè)消費(fèi)者連接中有3個(gè)channel.隊(duì)列數(shù)量小于等于15時(shí),綁定到同一個(gè)持久化direct交換器; 隊(duì)列數(shù)量大于15時(shí),綁定到兩個(gè)持久化direct交換器. 開啟management插件與top插件. 分別記錄優(yōu)化前與優(yōu)化后的消息發(fā)送速率,每種情況測(cè)試10分鐘,測(cè)試3次取平均值.

消息發(fā)送速率提高百分比的計(jì)算方法為： (優(yōu)化后消息發(fā)送速率-優(yōu)化前消息發(fā)送速率)/優(yōu)化前消息發(fā)送速率*100%.

消息發(fā)送速率平均提高百分比為： 不同隊(duì)列數(shù)量時(shí),消息發(fā)送速率提高百分比的算術(shù)平均值.

4.2 測(cè)試結(jié)果與分析

如圖5所示,在1個(gè)虛擬主機(jī)中,隨著隊(duì)列數(shù)量增加,消息發(fā)送速率先增加然后緩慢下降. 優(yōu)化后消息發(fā)送速率提高的比例是逐漸下降的. 1個(gè)隊(duì)列時(shí),優(yōu)化后的消息發(fā)送速率是優(yōu)化前的3.08倍; 2個(gè)隊(duì)列時(shí),優(yōu)化后的消息發(fā)送速率是優(yōu)化前的2.01倍; 15個(gè)隊(duì)列時(shí),消息發(fā)送速率提高40.9%; 30個(gè)隊(duì)列時(shí),消息發(fā)送速率提高40.3%. 隊(duì)列數(shù)量大于3時(shí),消息發(fā)送速率平均提高42.9%.如圖6所示,對(duì)消費(fèi)者確認(rèn)過程進(jìn)一步優(yōu)化后,在同樣的測(cè)試環(huán)境中,隨著隊(duì)列數(shù)量增加,優(yōu)化后的消息發(fā)送速率逐漸下降. 1個(gè)隊(duì)列時(shí),優(yōu)化后的消息發(fā)送速率取得最大值,是優(yōu)化前的3.48倍; 2個(gè)隊(duì)列時(shí),優(yōu)化后的消息發(fā)送速率是優(yōu)化前的2.16倍; 15個(gè)隊(duì)列時(shí),

圖5 優(yōu)化后消息發(fā)送速率對(duì)比圖

消息發(fā)送速率提高52.6%; 30個(gè)隊(duì)列時(shí),消息發(fā)送速率提高53.4%. 隊(duì)列數(shù)量大于3時(shí),消息發(fā)送速率平均提高56.5%.

圖6 繼續(xù)優(yōu)化后消息發(fā)送速率對(duì)比圖

優(yōu)化后不執(zhí)行消息持久化操作,減少部分內(nèi)存操作,使消息發(fā)送速率得到提高. 繼續(xù)優(yōu)化后,不會(huì)在BQ和隊(duì)列進(jìn)程處記錄消費(fèi)者確認(rèn)相關(guān)信息,減少了插入、查找、刪除等操作,進(jìn)一步提高了消息發(fā)送速率,但是在隊(duì)列數(shù)量較多時(shí)可靠性略有下降. 上述兩種優(yōu)化方法需要確保每個(gè)隊(duì)列至少有一個(gè)消費(fèi)者,適用于消費(fèi)速度很快的情形. 在生產(chǎn)者、消費(fèi)者、隊(duì)列數(shù)量較少時(shí)可以獲得更大的性能提升. 生產(chǎn)者重發(fā)消息的策略,可以根據(jù)實(shí)際應(yīng)用場(chǎng)景確定. 與改進(jìn)前類似,在異常情況下,消費(fèi)者可能收到重復(fù)的消息. 第一種優(yōu)化方法保留了完整的消費(fèi)者確認(rèn)過程,能夠較好地處理basic.reject與basic.nack等命令,消費(fèi)者可以拒絕接收某些消息. 第二種優(yōu)化方法簡(jiǎn)化了消費(fèi)者確認(rèn)過程,無法處理消費(fèi)者拒絕消息的情況,適用于消費(fèi)者只對(duì)消息進(jìn)行確認(rèn)的情況. 可以根據(jù)應(yīng)用程序?qū)π阅堋⒖煽啃缘牟煌枨笫褂孟鄳?yīng)的優(yōu)化方法.

5 結(jié)語

本文詳細(xì)分析了RabbitMQ中持久化小消息的確認(rèn)過程,將生產(chǎn)者確認(rèn)過程與消費(fèi)者確認(rèn)過程結(jié)合起來進(jìn)行優(yōu)化,使生產(chǎn)者可以獲知消費(fèi)者成功接收到消息,提高了持久化小消息的發(fā)送速率. 要使消息發(fā)送速率得到根本提高,可以重新設(shè)計(jì)RabbitMQ的架構(gòu)： 使用多個(gè)輕量級(jí)進(jìn)程實(shí)現(xiàn)邏輯隊(duì)列與邏輯channel,或集群部署使用.

1Rostanski M,Grochla K,Seman A. Evaluation of highly available and fault-tolerant middleware clustered architectures using RabbitMQ. Federated Conference on Computer Science and Information Systems. Warsaw,Poland. 2014. 879-884.

2Videla A,Williams JJW. RabbitMQ實(shí)戰(zhàn)： 高效部署分布式消息隊(duì)列. 汪佳南,譯. 北京： 電子工業(yè)出版社,2015.

3Ionescu VM. The analysis of the performance of RabbitMQ and ActiveMQ. 14th RoEduNet International Conference - Networking in Education and Research (RoEduNet NER).Craiova,Romania. 2015. 132-137.

4Vandikas K,Tsiatsis V. Performance evaluation of an IoT platform. 8th International Conference on Next Generation Mobile Apps,Services and Technologies. Oxford,UK. 2014.141-146.

5Dawar S,Fallon E,Bennet T,et al. An extensible architecture for mobile network management event distribution and rule processing - a performance evaluation.1st International Conference on Artificial Intelligence,Modelling and Simulation. Kota Kinabalu,Malaysia. 2013.451-456.

6Yang WJ,Liu XG,Zhang L,et al. Big data real-time processing based on storm. 12th IEEE International Conference on Trust,Security and Privacy in Computing and Communications. Melbourne,VIC,Australia. 2013.1784-1787.

7Cesarini F,Thompson S. Erlang編程指南. 慕尼黑Isar工作組,楊劍,譯. 北京： 機(jī)械工業(yè)出版社,2011.

8袁佳. 基于主機(jī)日志的入侵檢測(cè)系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[碩士學(xué)位論文]. 北京： 北京郵電大學(xué),2014.

9李帥. RabbitMQ進(jìn)程結(jié)構(gòu)分析與性能調(diào)優(yōu). https：//www.qcloud.com/community/article/164816001481011847.[2016-10-10].

10Persistence Configuration. http：//www.rabbitmq.com/persistence-conf.html. [2017-06-01]

11RabbitMQ performance measurements,part 1. http：//www.rabbitmq.com/blog/2012/04/17/rabbitmq-performancemeasurements-part-1/. [2012-04-17]

12RabbitMQ performance measurements,part 2. http：//www.rabbitmq.com/blog/2012/04/25/rabbitmq-performancemeasurements-part-2/. [2012-04-25]