南京郵電大學(xué)通信與信息工程學(xué)院 劉 棟 姚建國

引言

進(jìn)入21世紀(jì)以來，互聯(lián)網(wǎng)技術(shù)飛速發(fā)展，催生了一大批的智能終端設(shè)備，諸如智能電視、智能冰箱的成熟和普及意味著移動互聯(lián)網(wǎng)所帶來的將不局限于移動信息層面的變革，而是對我們生活的徹底顛覆。這已經(jīng)宣告智能家居時代的全面到來。而一些終端廠商也開始打造軟件和硬件統(tǒng)一化的智能家居云平臺。智能家居云平臺作為連接用戶和終端設(shè)備的關(guān)鍵橋梁，要考慮高并發(fā)情景，這對智能家居云平臺架構(gòu)的設(shè)計提出了更嚴(yán)格的要求。本文結(jié)合H3C智能家居項目，通過對RabbitMQ消息隊列的分析與研究，實現(xiàn)了RabbitMQ消息服務(wù)器在智能家居云平臺系統(tǒng)的具體應(yīng)用，并通過測試表明該設(shè)計可以滿足智能家居云平臺的性能要求。

1.RabbitMQ基本介紹

RabbitMQ是一個開源的AMQP實現(xiàn)。它主要特點是面向消息、路由、隊列，而且保證消息傳遞的高可靠性。服務(wù)器端采用的是Erlang語言編寫，支持多種客戶端，具有跨平臺性。它支持點對點傳輸，RPC（遠(yuǎn)程過程調(diào)用）、發(fā)布訂閱、分布式事務(wù)等多種消息交互模型。通常會用于在分布式系統(tǒng)中存儲轉(zhuǎn)發(fā)消息。而且RabbitMQ提供了圖形化的管理界面，這大大方便開發(fā)人員在相關(guān)問題上的開發(fā)定位。要熟悉RabbitMQ，首先要了解RabbitMQ中幾個重要的概念。

1.1 Broker

指的是消息隊列服務(wù)器實體。

1.2 Queue

用于存儲轉(zhuǎn)發(fā)消息的隊列，發(fā)送者將消息存入隊列中，接收者從隊列中取出消息進(jìn)行處理。

1.3 Exchange

發(fā)送方并不是直接發(fā)送消息給queue，而是先發(fā)送消息到交換器，交換器根據(jù)不同的路由規(guī)則將消息轉(zhuǎn)發(fā)到不同的隊列上。

1.4 routing key

routing key需要與Exchange Type及binding key一起使用。發(fā)送消息給Exchange時，通過指定routing key來決定消息流向哪里。

1.5 Exchange Type

Exchange Type會指定routingkey和Binding之間的匹配規(guī)則。RabbitMQ常用的Exchange Type有fanout、direct、topic、headers這四種這里主要簡單介紹前三種。

1.5.1 fanout

fanout類型的Exchange會把所有發(fā)送到該Exchange的消息路由到所有與它綁定的Queue中。

1.5.2 direct

direct類型的Exchange會把消息路由到那些binding key與routing key完全匹配的Queue中。

1.5.3 topic

由于溝槽輥上多個環(huán)形流道內(nèi)的流體特性相同[4]，故為了減輕計算機(jī)的運行負(fù)荷、節(jié)約計算時間，對輥殼式流漿箱實驗裝置的內(nèi)部流場進(jìn)行簡化，選取溝槽輥中的一個環(huán)形流道，用SOLIDWORKS軟件建立從均衡室入口至漿流出口的流場模型，再用 ICEM-CFD 軟件中的四面體網(wǎng)格劃分方法進(jìn)行網(wǎng)格劃分，經(jīng)反復(fù)嘗試，最終確定最佳網(wǎng)格尺寸為 4 mm，網(wǎng)格總數(shù)約20萬，劃分網(wǎng)格后的流道模型如圖3所示。模型具體參數(shù)與文獻(xiàn)[2，5]的建模參數(shù)相同。

topic類型的Exchange在匹配規(guī)則上進(jìn)行了擴(kuò)展，binding key中可以存在兩種特殊字符“*”與“#”，用于做模糊匹配。

2.RabbitMQ在智能家居云平臺的具體應(yīng)用

2.1 智能家居云平臺基本架構(gòu)設(shè)計

智能家居云平臺基本架構(gòu)如圖1所示。

圖1 智能家居云平臺基本架構(gòu)

智能家居云平臺項目針對云平臺多用戶，多設(shè)備接入的特征，采用了分布式服務(wù)、集群架構(gòu)設(shè)計，保證在高并發(fā)情形下業(yè)務(wù)的正常運行。三臺服務(wù)器部署成前臺集群作為前臺服務(wù)器，接收用戶和終端設(shè)備的請求參數(shù)。兩臺服務(wù)器部署成后臺集群作為后臺服務(wù)器，用來處理相關(guān)業(yè)務(wù)邏輯。不同的模塊實現(xiàn)不同的具體功能，大大提高了云平臺系統(tǒng)的可靠性，擴(kuò)展性和可用性。但是，原有的系統(tǒng)間通信方式使得系統(tǒng)間耦合嚴(yán)重，已無法滿足云平臺不同模塊之間越來越復(fù)雜的信息交互。RabbitMQ作為一種消息中間件，發(fā)送者只需要將消息存入RabbitMQ服務(wù)器即可，而接收者只需要取出消息進(jìn)行處理。這樣真正實現(xiàn)了系統(tǒng)間的解耦。

2.2 RabbitMQ的具體應(yīng)用

在RabbitMQ消息隊列的具體使用上，云平臺主要使用三種模式，第一種為“發(fā)后即忘”的普通模式。第二種為請求后要求立即響應(yīng)的RPC模式。第三種為發(fā)布訂閱模式。

2.2.1 普通模式

主要應(yīng)用于一些耗時較長的業(yè)務(wù)，前臺發(fā)布數(shù)據(jù)后即刻返回，后臺慢慢處理。首先定義了一個Exchang名稱為smarthome.rpc.exchange。它的Exchange type為direct，然后聲明一個前臺往后臺發(fā)送消息的隊列,名稱為smarthome.rpc.queue，設(shè)定Binding key為marthome.rpc.routekey，為其綁定一個完全匹配的routeing key為smarthome.rpc.routekey，所有后臺共同消費這個隊列。一個消息被一個后臺消費后即被清除。

2.2.2 RPC模式

主要用于兩塊業(yè)務(wù)：

(a )web頁面上的增刪改查（web前臺和后臺通信）

(b)websocket長連接之間的請求響應(yīng)（netty前臺和后臺通信）

以web業(yè)務(wù)為例，前臺發(fā)送消息后臺接收，前臺作為生產(chǎn)者，后臺作為消費者。模型流程和普通模式相同。但是，在RPC模式下，消息在后臺處理后要立即返回前臺。在這部分業(yè)務(wù)的處理上，沒有采用回調(diào)的方式返回消息，而是將后臺作為生產(chǎn)者，前臺作為消費者，構(gòu)造前臺返回隊列。

首先聲明消息的返回隊列，并且每個前臺服務(wù)器對應(yīng)一個消息返回的隊列，這樣在接收返回消息時才不會導(dǎo)致消息接收錯亂。每個返回隊列名字為smarthome.rpc.recive.queue_$ip ，該隊列所綁定routing key為smarthome.rpc.recive.route key_$ip，這里使用的后綴IP為前臺服務(wù)器IP，用來區(qū)分不同前臺隊列和前臺routing key。這樣各個前臺固定消費各自返回隊列中的消息。前臺服務(wù)器往后臺發(fā)送消息時，消息中附帶回復(fù)消息需要返回到那個前臺的routing key，這樣后臺消息處理完畢后，會使用前臺發(fā)送過來的routing key來進(jìn)行綁定到對應(yīng)的前臺隊列。保證消息被正確返回給發(fā)送請求消息的前臺。

2.2.3 發(fā)布訂閱模式

主要業(yè)務(wù)是各個服務(wù)器日志等級的修改。日志業(yè)務(wù)適用于所有的服務(wù)器，web項目和netty項目具有獨立的服務(wù)器。消息隊列設(shè)計了兩個exchange。一個為smarthome.fanout.exchange，另一個smarthome.netty.fanout.exchange。類型都為fanout。Fanout類型的exchange不需要指定routekey，往該exchange上發(fā)送消息會發(fā)送到所有該exchange下綁定的所有的queue。所以只需要每個項目服務(wù)器聲明一個接收隊列，綁定到該exchange下。這樣每個項目服務(wù)器固定消費接收隊列中的消息，即可以訂閱到發(fā)布的信息。

3.RabbitMQ集群方式

3.1 默認(rèn)集群模式

RabbitMQ是用erlang開發(fā)的，因為erlang天生就是一門分布式語言所以集群非常方便。RabbitMQ帶有默認(rèn)的集群模式。

一個RabbitMQ集群中的不同節(jié)點擁有相同的元數(shù)據(jù)。所有的數(shù)據(jù)和狀態(tài)都會在所有節(jié)點上復(fù)制的。但是每個節(jié)點的消息隊列是不可復(fù)制的。默認(rèn)的集群模式中當(dāng)一個節(jié)點發(fā)生故障時，消費者可以從另外的節(jié)點繼續(xù)接收消息。RabbitMQ默認(rèn)集群模式，并不保證隊列的高可用性，盡管交換機(jī)等可以復(fù)制到集群里的任何一個節(jié)點，但是隊列內(nèi)容不會復(fù)制，雖然該模式解決一部分節(jié)點壓力，但隊列節(jié)點宕機(jī)直接導(dǎo)致該隊列無法使用，只能等待故障恢復(fù)。而且這種每個節(jié)點共享元數(shù)據(jù)的模式可能還會造成一個問題，一個節(jié)點發(fā)生故障，其他節(jié)點可能會因為同樣的原因發(fā)生同樣的故障。

3.2 鏡像集群模式

鏡像集群模式與默認(rèn)模式相比，它會在各個節(jié)點都會復(fù)制一份隊列消息，當(dāng)一個節(jié)點發(fā)生故障時，該節(jié)點隊列中的消息可以在其他節(jié)點中繼續(xù)被消費，不會丟失。但是，鏡像模式有一個很大的缺點，那就是當(dāng)節(jié)點非常多的時候，消息在各個節(jié)點間的復(fù)制同步，會降低系統(tǒng)吞吐量，對帶寬也會有一定影響，從而降低整個系統(tǒng)性能。

3.3 主備集群模式

由于云平臺不僅需要保證高可靠性，還要保證系統(tǒng)性能，所以采用主備集群模式，這種模式為一對主/備獨立服務(wù)器，這是真正的無共享架構(gòu)，主服務(wù)器和備用服務(wù)器之間沒有協(xié)作，所以任何影響到主服務(wù)器的問題不會自動轉(zhuǎn)移到備用服務(wù)器上。分隔的足夠徹底，可以運行不同版本的RabbitMQ。安裝一臺haproxy代理服務(wù)器，這臺服務(wù)器的主要用途是發(fā)生處業(yè)務(wù)故障時，進(jìn)行業(yè)務(wù)轉(zhuǎn)移。

4.系統(tǒng)測試

RabbitMQ服務(wù)器作為連接前臺和后臺通信的關(guān)鍵橋梁，為了保證云平臺系統(tǒng)的高可靠性，在功能測試之后進(jìn)行一定的壓力測試。

使用Loadrunner測試工具，構(gòu)造500虛擬用戶并發(fā)訪問云平臺，系統(tǒng)在4分鐘后到達(dá)500并發(fā)量，并且一直持續(xù)20分鐘，可以發(fā)現(xiàn)在這20分鐘內(nèi)，系統(tǒng)的平均響應(yīng)時間大約在4秒左右，每秒點擊數(shù)在150上下。

從測試結(jié)果分析報告，可見在測試環(huán)境中500并發(fā)下，平均響應(yīng)是3.174秒，滿足云平臺5秒響應(yīng)要求。事務(wù)成功率達(dá)95%以上，滿足業(yè)務(wù)要求。

5.結(jié)束語

本文在已有的智能家居云平臺基礎(chǔ)上，通過對RabbitMQ的研究，實現(xiàn)了RabbitMQ服務(wù)器在多前臺多后臺分布式系統(tǒng)中的應(yīng)用模式。解決了多模塊之間耦合嚴(yán)重問題。RabbitMQ的高可靠性是其他消息中間件不能相比的，這也是平臺系統(tǒng)采用RabbitMQ服務(wù)器的主要原因之一。而且RabbitMQ服務(wù)器提供了可視化的監(jiān)控頁面，這有利于對平臺系統(tǒng)的監(jiān)控和維護(hù)。RabbitMQ消息隊列實現(xiàn)了可靠、有效的信息交互模式。為整個智能家居云平臺架構(gòu)提供了堅實可靠的基礎(chǔ)。