智能停車系統(tǒng)中消息中間件的設(shè)計(jì)與實(shí)現(xiàn)

陳思媛，易國洪*，2，金 旺

1.武漢工程大學(xué)計(jì)算機(jī)科學(xué)與工程學(xué)院，湖北 武漢 430205；2.智能機(jī)器人湖北省重點(diǎn)實(shí)驗(yàn)室（武漢工程大學(xué)），湖北 武漢 430205

現(xiàn)如今汽車的擁有量達(dá)到一個相當(dāng)龐大的數(shù)字，導(dǎo)致交通擁堵問題日益嚴(yán)重［1］，智慧停車解決城市“停車難”問題已刻不容緩。智能立體停車庫以獨(dú)特的占地面積少［2］，交互敏捷等特點(diǎn)成為新時(shí)代解決停車問題的關(guān)鍵。其中，移動終端和應(yīng)用服務(wù)器之間的通訊存在穩(wěn)定性、實(shí)時(shí)性和準(zhǔn)確性等方面的問題。參考如今市面上使用較廣的幾種開源消息中間件，例如ActiveMQ、kafka、ZeroMQ等，經(jīng)過測試發(fā)現(xiàn)ActiveMQ 采用消息推送方式，所以最適合的場景是默認(rèn)消息都可在短時(shí)間內(nèi)被消費(fèi)，當(dāng)消息隊(duì)列流量達(dá)到峰值時(shí)，容易造成消息在消費(fèi)者客戶端堆積［3］，這與智能停車系統(tǒng)要求在短時(shí)間內(nèi)完成大量的數(shù)據(jù)請求特性不符；Kafka 特有的異步刷盤機(jī)制會導(dǎo)致在處理海量數(shù)據(jù)時(shí)產(chǎn)生過高開銷甚至出錯等問題［4］；而ZeroMQ 的并發(fā)是通過通訊隊(duì)列使用無鎖操作［5］實(shí)現(xiàn)的，不能保證線程安全。傳統(tǒng)的同步點(diǎn)對點(diǎn)通信由于應(yīng)用程序與服務(wù)器之間一對一的通信方式無法滿足大量用戶、多臺中控同時(shí)請求通信的需求，綜合考慮，本文設(shè)計(jì)了一種智能停車異步消息中間件（smart car asynchronous messaging middleware，SCAMM）較好地解決了以上的問題。SCAMM 采用基于消息的分布式通信模式，消息生產(chǎn)者（客戶端）將攜帶標(biāo)志的消息發(fā)布到消息代理服務(wù)器，再由消息代理服務(wù)器發(fā)向已注冊該標(biāo)志的消費(fèi)者（對應(yīng)的服務(wù)器）。這種模式下實(shí)現(xiàn)了生產(chǎn)者和消費(fèi)者之間的松耦合，同時(shí)基于Java 非阻塞（non-blocking input output，NIO）事件驅(qū)動模型的異步通信技術(shù)能滿足大量用戶同一時(shí)刻發(fā)送請求，在此基礎(chǔ)上對數(shù)據(jù)的粘包拆包問題進(jìn)行了處理。

SCAMM 消息中間件在智能停車系統(tǒng)中的應(yīng)用實(shí)例如圖1 所示。當(dāng)用戶點(diǎn)擊停車按鈕時(shí)，客戶端將請求數(shù)據(jù)發(fā)送到消息中間件，隊(duì)列管理器將讀取消息并寫入對應(yīng)的通道，通道以輪詢的方式發(fā)送消息至中控端，用戶停車成功則在客戶端告知停車完成，車位不足時(shí)則返回停車失敗。智能停車系統(tǒng)的重點(diǎn)在于上下班的高峰期對可停車位的資源搶奪，這一過程要求系統(tǒng)既要應(yīng)對短時(shí)間內(nèi)高并發(fā)多目標(biāo)中控的指令請求，又要保證指令準(zhǔn)確完整的送達(dá)對應(yīng)中控機(jī)，SCAMM 消息中間件能夠很好解決這一問題。

圖1 SCAMM 體系結(jié)構(gòu)圖Fig.1 Architecture of SCAMM

1 相關(guān)技術(shù)

1.1 消息模型

消息中間件中支持的消息模型分為兩種：點(diǎn)對點(diǎn)模型（peer to peer，P2P）和發(fā)布/訂閱模型。圖2 為兩種通信模型圖。

圖2 兩種通信模型圖：（a）點(diǎn)對點(diǎn)，（b）發(fā)布者/訂閱者Fig.2 Two-communication models：（a）P2P，（b）publisher/subscriber

P2P 模型的主體有3 個：消息的發(fā)送者，消息轉(zhuǎn)發(fā)隊(duì)列以及消息的接收者。消息產(chǎn)生后通過發(fā)送者發(fā)送到一個特定的消息隊(duì)列，排隊(duì)轉(zhuǎn)發(fā)給被接受者，消息被接收者接受或者過期之后會被丟出消息隊(duì)列，一個消息只能被一個接收者所接受，當(dāng)接受者離線時(shí)，這條消息也會在消息隊(duì)列中被移除。發(fā)布/訂閱模式下的主題有3 個：發(fā)布者，訂閱者和主題。發(fā)布者指定消息的主題，并將消息主動發(fā)送到主題的通道中或者等待訂閱者來輪詢，訂閱者可以通過訂閱主題來使用指定通道中的消息。發(fā)布/訂閱模式有以下特點(diǎn)：每個訂閱者可以訂閱多個主題，每個主題中的消息可以被所有訂閱者訂閱，可以實(shí)現(xiàn)一對多的消息傳遞。

1.2 異步通信

異步通信是指消息在生產(chǎn)者和消費(fèi)者之間的收發(fā)不需要通過公共的時(shí)鐘信號來控制，而是采用異步應(yīng)答方式來實(shí)現(xiàn)雙方的通信［6］。消息中間件SCAMM 采用Java NIO 異步非阻塞I/O 模型來實(shí)現(xiàn)異步通信，Java NIO 是在JDK 1.4 開始提供新的API［7］，基于事件驅(qū)動模型開發(fā)［8］，以塊的方式處理數(shù)據(jù)［9］，通過雙向通道（channel）進(jìn)行傳輸。異步通信機(jī)制的本質(zhì)是當(dāng)應(yīng)用進(jìn)程向CPU 發(fā)送一個I/O 請求，如果此時(shí)內(nèi)核內(nèi)沒有可用資源被調(diào)用，內(nèi)核會向客戶端返回一個錯誤碼，客戶端進(jìn)程會有可用資源的時(shí)間再次進(jìn)行請求操作，這樣就避免了進(jìn)程的阻塞，這種往返的操作也被稱為輪詢［10］?？梢詫惒酵ㄐ胖械姆亲枞鸌/O 模型用以下的偽代碼來表示：

1.3 消息隊(duì)列

消息隊(duì)列是指消息由生產(chǎn)者發(fā)送到1 個擁有特定標(biāo)志的虛擬通道，消費(fèi)者連接到這個特定通道上獲取通道中的消息。在分布式和異構(gòu)環(huán)境中使用消息隊(duì)列技術(shù)可以很大程度地減少系統(tǒng)的耦合，消息隊(duì)列對消息的生產(chǎn)者和消費(fèi)者的語言、平臺不做要求，只需要在同一套編碼規(guī)范下即可完成通信。當(dāng)使用消息隊(duì)列時(shí)，生產(chǎn)者和消費(fèi)者需要知道隊(duì)列的標(biāo)志，消息才能夠被發(fā)送到指定標(biāo)志下的隊(duì)列。消息在隊(duì)列中會按照先進(jìn)先出的順序被轉(zhuǎn)發(fā)給消費(fèi)者。在這種模式下，生產(chǎn)者和消費(fèi)者可以不必同時(shí)處在工作狀態(tài)，虛擬通道會按照先進(jìn)先出的順序在消費(fèi)者能夠正常工作后將消息轉(zhuǎn)發(fā)給消費(fèi)者，1 條消息只能被一個消費(fèi)者接受，當(dāng)這條消息被使用或者過期后，將會被拋出消息隊(duì)列，當(dāng)消費(fèi)者接收到消息后將返回通道1 個確認(rèn)信息。整個過程中生產(chǎn)者只需要發(fā)送1 條消息后無需等待，消費(fèi)者也只需從隊(duì)列中讀取消息進(jìn)行執(zhí)行［11］，摒棄了傳統(tǒng)應(yīng)用中通信雙方需要同步執(zhí)行的缺點(diǎn)。

2 消息中間件的設(shè)計(jì)

2.1 SCAMM 的模型

消息中間件是1 種消息代理，是統(tǒng)一消息收發(fā)的接口，通過高效可靠的消息傳遞機(jī)制實(shí)現(xiàn)跨平臺，跨語言進(jìn)行數(shù)據(jù)交換［12］。作為軟件中間層，消息中間件通過采用同步或異步的通信方式來達(dá)到穩(wěn)定可靠的數(shù)據(jù)交流，在分布式環(huán)境下擴(kuò)展進(jìn)程間的通信［13］。本文采用形式化語言巴科斯范式（backus naur form，BNF）進(jìn)行描述消息中間件，BNF 的優(yōu)點(diǎn)在于它描述的是軟件的抽象結(jié)構(gòu)，無需考慮其具體實(shí)現(xiàn)細(xì)節(jié)。使用BNF 語言既避免了在描述中間件語義上的二義性、模糊性，又在垂直方向上明確各部分繼承父對象的規(guī)格說明［14］。中間件的描述需要明確兩個方面的信息：中間件操作來實(shí)現(xiàn)，這些操作包含輸入輸出參數(shù)和約束的構(gòu)成和各構(gòu)成模塊的行為信息，每個部件都有一個或多個接口實(shí)現(xiàn)，每個接口都有一個或多個條件。以下給出了中間件的主要組成部分和各個部分需要實(shí)現(xiàn)的方法。

＜SCAMM＞：：=＜Function＞* ＜InterFace＞* ＜Message Scheduling ＞

＜Function＞：：=＜ChannelHandle＞＜start＞＜close＞＜transport ＞［Heart-beat］［link-protect］

＜InteFace＞：：=＜Connection＞＜message class＞＜Communication＞［self-Protocol］

＜Message Scheduing ＞：：=＜message queue|message topic＞

消息中間件SCAMM 定義為3 種成分：至少1種的Function 功能（Function）、至少1 個外部接口（InterFace）和1 種確定的Message Scheduing（消息調(diào)度類型）。功能模塊包含邏輯處理模塊、啟動模塊、關(guān)閉模塊、傳輸通信協(xié)議（transmission control protocol，TCP）長連接心跳檢測模塊、鏈路保護(hù)模塊，每個子模塊實(shí)現(xiàn)的功能不同，協(xié)同實(shí)現(xiàn)消息在中間件內(nèi)部分發(fā)過程。外部接口模塊包含通訊接口、連接接口以及自定義的消息格式接口，外部接口模塊是為了使消息中間件不限制于單一類型的客戶端或者通信協(xié)議，降低了系統(tǒng)的耦合程度同時(shí)保證了消息中間件良好的拓展性。消息中間件需要明確某1 種通信模式，通常通信模型分為消息隊(duì)列或者主題（topic）。

圖3 SCAMM 的系統(tǒng)功能模塊圖Fig.3 Function module diagram of SCAMM system

在智能停車消息中間件SCAMM 通信模型中使用Java NIO 事件驅(qū)動模型來實(shí)現(xiàn)異步通信。智能停車系統(tǒng)中需要考慮消息的高并發(fā)和準(zhǔn)確性，在SCAMM 模型中采用Channel 來傳輸數(shù)據(jù)，這個通道連接起客戶端和中控端，當(dāng)某1 個中控機(jī)與服務(wù)器建立連接后，在服務(wù)器設(shè)置的監(jiān)聽器立即啟動連接模塊為這個中控機(jī)注冊1 個全新的Channel TCP 長連接并擁有唯一標(biāo)志，有標(biāo)志了發(fā)往這個中控的消息會經(jīng)由Channel 轉(zhuǎn)發(fā)。在整個通信過程中，消息首先由生產(chǎn)者（客戶端）傳遞給SCAMM 消息中間件，通過消息管理模塊調(diào)用ChannelRead 讀取消息標(biāo)志，根據(jù)消息標(biāo)志寫入對應(yīng)Channel 的消息隊(duì)列中，在經(jīng)過自定義的消息格式編碼后通過消息轉(zhuǎn)發(fā)模塊發(fā)送給中控，中控接收到數(shù)據(jù)包后會回復(fù)1 個數(shù)據(jù)包，這個回復(fù)包再通過消息轉(zhuǎn)發(fā)模塊的接收方法獲取，解碼后從原通道返回至消息隊(duì)列，消息隊(duì)列發(fā)送給客戶端。SCAMM 消息中間件通信的系統(tǒng)結(jié)構(gòu)如圖3 所示。

2.2 SCAMM 的設(shè)計(jì)

SCAMM 消息中間件服務(wù)端分為5 個模塊：連接模塊、長連接心跳監(jiān)測模塊、消息封裝模塊、消息管理模塊和消息轉(zhuǎn)發(fā)模塊。連接模塊通過監(jiān)聽中控服務(wù)狀態(tài)來建立與服務(wù)器的TCP 長連接，當(dāng)遠(yuǎn)程中控失去連接時(shí)，調(diào)用close（）方法釋放掉已注冊的通道信息，下次遠(yuǎn)程中控上線后重新注冊。長連接心跳監(jiān)測模塊通過定時(shí)發(fā)送心跳報(bào)文監(jiān)測通道是否存活，及時(shí)關(guān)閉失活通道并重新注冊該通道避免了服務(wù)端可能存在的消息丟失的情況。消息封裝模塊由SmartCarDecoder 類通過自定義通信協(xié)議，保證了數(shù)據(jù)傳輸?shù)碾[蔽性和安全性，并且通過在服務(wù)端和客戶端的pipeline 上加上相應(yīng)的解碼器解決了TCP 的粘包、拆包問題；消息管理模塊的ChannelHandle 組件實(shí)現(xiàn)了服務(wù)器對從客戶端接受的數(shù)據(jù)的處理。消息轉(zhuǎn)發(fā)模塊通過transport類來實(shí)現(xiàn)消息傳遞。

2.2.1 ChannelHandle API 啟動Server 時(shí)，進(jìn)行服務(wù)器初始化，這一步的操作包括讀取主機(jī)的IP 地址、監(jiān)聽進(jìn)行socket 通信的端口、創(chuàng)建ChannelHandle 組件并注冊相對應(yīng)中控端（消費(fèi)者）的消息通道（Channel）。通過讀取到客戶端發(fā)送過來的消息的相關(guān)參數(shù)，ChannelHandle 組件進(jìn)行一系列相應(yīng)的通信過程的接發(fā)處理，ChannelHandle 組件存在兩個比較重要的子接口，ChannelInboundHandle 處理入站數(shù)據(jù)和各種變化的子接口，ChannelOutboundHandle 處理出站數(shù)據(jù)并且包含各種攔截操作的命令的子接口。對于ChannelInboundHandle子接口，表1 給出了相關(guān)方法的描述。

表1 ChannelInboundHandle 的方法描述Tab.1 Methods description of channelInboundHandle class

當(dāng)某個ChannelInboundHandle 的實(shí)現(xiàn)重寫了ChannelRead（）方法時(shí)，它將負(fù)責(zé)顯式的釋放與池化的ByteBuf 實(shí)例相關(guān)的內(nèi)存。最后，將已經(jīng)啟動的Channel 保存在列表中，該列表保存所有當(dāng)前活動的中控端（消費(fèi)者）的長連接。

2.2.2 SmartCarDecoder 類 消息中間件協(xié)議不僅定義了進(jìn)行信息交換的通信方式，而且間接體現(xiàn)了協(xié)議支持的系統(tǒng)結(jié)構(gòu)方式［15］。當(dāng)客戶端發(fā)送一條消息或者服務(wù)端接收到一條消息時(shí)，就會發(fā)生一次數(shù)據(jù)交換，通過自定義消息的編碼器與解碼器可以保證消息的獨(dú)立性與隱私性。入站消息會被解碼，解碼器將接收到的字節(jié)流轉(zhuǎn)換成中間格式j(luò)son 字符流，再由字符流轉(zhuǎn)換成1 個Java 對象，出站消息的模式是相反方向的，編碼器將對象轉(zhuǎn)換成字符流，再通過字符流轉(zhuǎn)化成字節(jié)流與消費(fèi)者進(jìn)行網(wǎng)絡(luò)數(shù)據(jù)的通信。本文設(shè)計(jì)的中間件使用的是基于長度的協(xié)議的解碼器，基于長度的協(xié)議通過它的長度編碼到幀的頭部來定義幀，而不是使用某種特殊的分隔符來標(biāo)記它的結(jié)束。協(xié)議開始使用標(biāo)準(zhǔn)數(shù)據(jù)包包頭整型占4 B，傳輸數(shù)據(jù)的長度為整型，占4 B，同時(shí)為了防止socket 流的攻擊，傳輸?shù)臄?shù)據(jù)長度不應(yīng)該超過2 048 位。服務(wù)端消息轉(zhuǎn)發(fā)模塊通過讀取并匹配提取的幀的數(shù)據(jù)來分發(fā)消息。SmartCarDecoder 類同時(shí)解決了消息的粘包、拆包問題。消息在客戶端和服務(wù)端之間是以一種流的方式來進(jìn)行轉(zhuǎn)播的。對于應(yīng)用層而言，客戶端發(fā)送的是一個個獨(dú)立完整的數(shù)據(jù)包，而在數(shù)據(jù)鏈路層、傳輸層或網(wǎng)絡(luò)層這種底層會根據(jù)TCP 緩沖區(qū)的實(shí)際大小進(jìn)行包的劃分，就可能會出現(xiàn)將一個完整的數(shù)據(jù)包拆分成多個包發(fā)送或者將多個包封裝成一個大的數(shù)據(jù)包發(fā)送，這就是TCP 的粘包、拆包。當(dāng)出現(xiàn)粘包、拆包問題時(shí)，系統(tǒng)中的消息就會成為不可讀的消息，SmartCarDecoder 類將消息分為消息頭和消息體，消息頭中包含表示消息總長度的字段，該解碼器能夠在獲取消息頭的時(shí)候解析出消息長度，然后向后讀取該長度的內(nèi)容。對于實(shí)現(xiàn)中間件的編解碼類，表2 給出了相關(guān)方法的描述。

表2 SmartCarDecoder類的方法描述Tab.2 Methods description of SmartCarDecoder class

2.2.3 transport 類的實(shí)現(xiàn) ChannelHandle 組件通過transport 類實(shí)現(xiàn)消息傳遞。transport 類的方法描述如表3 所示。當(dāng)服務(wù)器需要轉(zhuǎn)發(fā)一條消息給消費(fèi)者時(shí)，transport 類通過其SendMessage（）方法輪詢的發(fā)送隊(duì)列中的消息。消息轉(zhuǎn)發(fā)模塊線程將一直處于輪詢狀態(tài)直到調(diào)用了StopTransport（）方法［11］，當(dāng)服務(wù)器接收到消費(fèi)者的反饋時(shí)，通過ReceiveMessage（）方法將反饋消息通過自定義協(xié)議封裝傳回給客戶端。

2.2.4 心跳檢測類的實(shí)現(xiàn) 在異步長連接中，客戶端發(fā)送正常報(bào)文時(shí)可能發(fā)生通道連接異常的情況，為了監(jiān)測通道連接是否正常，SCAMM 消息中間件在服務(wù)端定時(shí)發(fā)送心跳報(bào)文，當(dāng)心跳報(bào)文發(fā)送或者解析后不匹配時(shí)則認(rèn)為該通道失活，服務(wù)端關(guān)閉該通道并重新注冊激活。該類使用線程避免了心跳報(bào)文與正常通信報(bào)文在同一個套接字連接中產(chǎn)生的資源交叉，使用線程池對心跳線程進(jìn)行管理避免了通道數(shù)過多時(shí)產(chǎn)生的服務(wù)器資源占用過多的問題，線程間的通信可使用全局變量從而簡化程序復(fù)雜度；使用線程內(nèi)部機(jī)制——靜態(tài)互斥量進(jìn)行正常報(bào)文和心跳報(bào)文的同步，程序簡單可靠［16］。心跳檢測類的方法描述如表4 所示。

表3 transport類的方法描述Tab.3 Methods description of transport class

表4 心跳檢測的方法描述Tab.4 Methods description of heartbeat detection class

2.2.5 Abstract-Message 抽象消息類 Message 對象由抽象消息類創(chuàng)建，該類定義了一條消息需要具備的內(nèi)容，包括消息的指令類型、目標(biāo)地址標(biāo)記、預(yù)約時(shí)長、車牌號、用戶ID 等等，通過格式化編碼將這些信息封裝成一個對象，用于消息中間件的接發(fā)。抽象消息類的參數(shù)如表5 所示。

表5 Abstract-Message 抽象消息類的參數(shù)描述Tab.5 Parametric description of Abstract-Message class

3 實(shí)驗(yàn)部分

3.1 實(shí)驗(yàn)環(huán)境

為了檢驗(yàn)SCAMM 中間件是否能夠提高智能停車系統(tǒng)中指令接受的準(zhǔn)確率，利用單一因素實(shí)時(shí)實(shí)驗(yàn)原理進(jìn)行了實(shí)驗(yàn)。實(shí)驗(yàn)中的計(jì)算機(jī)運(yùn)行的是Microsoft Windows10 x64，具 有1 個IntelCore I5-6 200U 處理器，雙核四線程、8 GB 的RAM 和一個500 GB 磁盤。將服務(wù)端和客戶端部署在同一臺計(jì)算機(jī)上同時(shí)結(jié)束所有非必要的進(jìn)程以防止對實(shí)驗(yàn)結(jié)果的影響。使用測試工具postman 檢查響應(yīng)數(shù)據(jù)包（Response Body）是否等于約定消息長度和內(nèi)容，當(dāng)Response Body 的返回值與消息完全匹配時(shí)返回true，否則返回false，每次測試重復(fù)3 次并采取平均值進(jìn)行記錄。

3.2 消息的準(zhǔn)確率對比試驗(yàn)

實(shí)驗(yàn)選擇socket 點(diǎn)對點(diǎn)通信、擁有高吞吐量性能的中間件kafka 和SCAMM 中間件并分別將3 種通訊方式應(yīng)用于智能停車系統(tǒng)進(jìn)行了測試。由于SCAMM 自定義協(xié)議類SmartCarDecoder 用來處理消息粘包、拆包的特點(diǎn)，就并發(fā)請求數(shù)量級、消息大小這兩個方面進(jìn)行實(shí)驗(yàn)，兩次實(shí)驗(yàn)均采用單一變量原則。在消息數(shù)量對準(zhǔn)確率的影響實(shí)驗(yàn)中，固定每次發(fā)送的消息大小為256 B，依次改變并發(fā)請求總數(shù)100、500、1 000、2 000、5 000，記錄測試工具postman 提供的完全匹配成功數(shù)和匹配失敗數(shù)；在消息大小對準(zhǔn)確率的影響實(shí)驗(yàn)中，固定請求總數(shù)1 000，依次改變消息的大小256 B、512 B、1 kB、5 kB、10 kB，記錄測試工具postman 提供的完全匹配成功數(shù)和匹配失敗數(shù)。以上每次實(shí)驗(yàn)前結(jié)束所有無關(guān)進(jìn)程避免對實(shí)驗(yàn)造成干擾，每次實(shí)驗(yàn)重復(fù)3 次并計(jì)平均值。

表6 為智能停車系統(tǒng)中采用傳統(tǒng)點(diǎn)對點(diǎn)的socket 通信、使用kafka 中間件和使用SCAMM 中間件進(jìn)行不同并發(fā)請求數(shù)下的對比。由表6 可知，當(dāng)并發(fā)請求數(shù)＜500 時(shí)，兩種情況下指令的準(zhǔn)確率相差無幾；當(dāng)并發(fā)數(shù)量＞1 000 時(shí)，SCAMM 中間件能夠明顯的優(yōu)于兩者。SCAMM 在不同并發(fā)請求數(shù)下的準(zhǔn)確率為100%。

表7 為智能停車系統(tǒng)中采用傳統(tǒng)點(diǎn)對點(diǎn)的socket 通信、使用kafka 中間件和使用SCAMM 中間件在不同消息規(guī)模下通信的準(zhǔn)確率對比。由表7可知，當(dāng)消息長度＜1 kB 時(shí)，3 種情況都表現(xiàn)了良好的準(zhǔn)確率；當(dāng)消息長度＞1 kB 時(shí)，SCAMM 能夠明顯的優(yōu)于傳統(tǒng)的socket 通信；當(dāng)消息長度≥10 kB 時(shí)，SCAMM 中間件的準(zhǔn)確率比kafka 中間件的準(zhǔn)確率提高了14%，比socket 點(diǎn)對點(diǎn)通信提高了32%。

由實(shí)驗(yàn)結(jié)果可知，在高并發(fā)請求數(shù)和大規(guī)模消息長度情況下，SCAMM 中間件能夠顯著提高消息的準(zhǔn)確率。

表6 不同并發(fā)數(shù)下準(zhǔn)確率實(shí)驗(yàn)對比Tab.6 Comparison of accuracy rates of different requests

表7 不同消息長度下準(zhǔn)確率實(shí)驗(yàn)對比Tab.7 Comparison of accuracy rates of different message sizes

4 結(jié) 論

在大型企業(yè)中消息中間件的應(yīng)用具有十分廣闊的前景，目前，基于消息的異步分布式通信設(shè)計(jì)的消息中間件SCAMM 已經(jīng)在實(shí)例中取得良好應(yīng)用，有著巨大的發(fā)展空間。相比于傳統(tǒng)應(yīng)用中的同步點(diǎn)對點(diǎn)通信來實(shí)現(xiàn)消息傳遞的系統(tǒng)，基于消息的異步分布式通信設(shè)計(jì)的消息中間件能夠提供更穩(wěn)定，擴(kuò)展性更好的中間橋梁，同時(shí)使系統(tǒng)在高并發(fā)量請求下仍然能夠高效的處理數(shù)據(jù)。SCAMM 忽略了發(fā)送方和接收方的平臺異構(gòu)性，簡化了集成分布式系統(tǒng)的難度，降低了維護(hù)系統(tǒng)的成本。SCAMM 中間件通過自定義的通信協(xié)議和心跳監(jiān)測模塊，能夠有效的保持指令傳輸過程中的安全性，提高指令被接收的準(zhǔn)確度。