RabbitMQ在智能家居云平臺中的研究與應用

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

引言

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

1.RabbitMQ基本介紹

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

1.1 Broker

指的是消息隊列服務器實體。

1.2 Queue

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

1.3 Exchange

發(fā)送方并不是直接發(fā)送消息給queue，而是先發(fā)送消息到交換器，交換器根據(jù)不同的路由規(guī)則將消息轉發(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)形流道內的流體特性相同[4]，故為了減輕計算機的運行負荷、節(jié)約計算時間，對輥殼式流漿箱實驗裝置的內部流場進行簡化，選取溝槽輥中的一個環(huán)形流道，用SOLIDWORKS軟件建立從均衡室入口至漿流出口的流場模型，再用 ICEM-CFD 軟件中的四面體網(wǎng)格劃分方法進行網(wǎng)格劃分，經(jīng)反復嘗試，最終確定最佳網(wǎng)格尺寸為 4 mm，網(wǎng)格總數(shù)約20萬，劃分網(wǎng)格后的流道模型如圖3所示。模型具體參數(shù)與文獻[2，5]的建模參數(shù)相同。

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

2.RabbitMQ在智能家居云平臺的具體應用

2.1 智能家居云平臺基本架構設計

智能家居云平臺基本架構如圖1所示。

圖1 智能家居云平臺基本架構

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

2.2 RabbitMQ的具體應用

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

2.2.1 普通模式

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

2.2.2 RPC模式

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

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

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

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

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

2.2.3 發(fā)布訂閱模式

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

3.RabbitMQ集群方式

3.1 默認集群模式

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

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

3.2 鏡像集群模式

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

3.3 主備集群模式

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

4.系統(tǒng)測試

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

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

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

5.結束語

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