999精品在线视频,手机成人午夜在线视频,久久不卡国产精品无码,中日无码在线观看,成人av手机在线观看,日韩精品亚洲一区中文字幕,亚洲av无码人妻,四虎国产在线观看 ?

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

2018-08-31 05:54:42南京郵電大學通信與信息工程學院姚建國
電子世界 2018年16期

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

引言

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

1.RabbitMQ基本介紹

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

1.1 Broker

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

1.2 Queue

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

1.3 Exchange

發送方并不是直接發送消息給queue,而是先發送消息到交換器,交換器根據不同的路由規則將消息轉發到不同的隊列上。

1.4 routing key

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

1.5 Exchange Type

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

1.5.1 fanout

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

1.5.2 direct

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

1.5.3 topic

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

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

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

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

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

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

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

2.2 RabbitMQ的具體應用

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

2.2.1 普通模式

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

2.2.2 RPC模式

主要用于兩塊業務:

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

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

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

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

2.2.3 發布訂閱模式

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

3.RabbitMQ集群方式

3.1 默認集群模式

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

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

3.2 鏡像集群模式

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

3.3 主備集群模式

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

4.系統測試

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

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

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

5.結束語

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

主站蜘蛛池模板: 国产真实乱子伦视频播放| 欧美精品在线免费| 色综合狠狠操| 男人的天堂久久精品激情| 高清精品美女在线播放| 国产精品久久久久久久久| 成人一级黄色毛片| 成人毛片免费观看| 日韩国产一区二区三区无码| 色婷婷天天综合在线| 麻豆精品视频在线原创| 国产在线自乱拍播放| 精品国产一区二区三区在线观看| 国产视频a| 日本黄色不卡视频| 国产不卡一级毛片视频| 色国产视频| 亚洲美女AV免费一区| 99re热精品视频国产免费| 久热re国产手机在线观看| 欧美色综合网站| 亚洲成在人线av品善网好看| 激情综合五月网| AV不卡无码免费一区二区三区| 久久久国产精品无码专区| 一级毛片在线直接观看| 99激情网| 国产探花在线视频| 久久青草免费91线频观看不卡| 亚洲嫩模喷白浆| 99视频在线看| 色哟哟国产精品| a天堂视频| 午夜国产理论| 亚洲国产一区在线观看| 97国产精品视频人人做人人爱| 一级毛片免费观看不卡视频| 国产成人综合亚洲网址| 波多野结衣久久精品| 国产av一码二码三码无码| 一级看片免费视频| 99久久精品美女高潮喷水| 国产乱视频网站| 国产精品99在线观看| 久久久精品国产亚洲AV日韩| 欧美中文字幕无线码视频| 国产高清不卡视频| 欧美一区国产| 99热国产这里只有精品无卡顿"| 欧美色综合网站| 国产国语一级毛片在线视频| 久久精品娱乐亚洲领先| 久久国产毛片| 亚洲成人动漫在线| 亚洲一区二区无码视频| 午夜a视频| 日本欧美中文字幕精品亚洲| 国产在线专区| 色婷婷亚洲十月十月色天| 亚洲精品第一在线观看视频| 国产一区免费在线观看| 亚洲精品日产AⅤ| 国产在线观看第二页| 成人在线天堂| 视频一区视频二区日韩专区| 久久综合色播五月男人的天堂| 欧美成人手机在线视频| 58av国产精品| 日本久久网站| 欧美色视频日本| 国产中文一区二区苍井空| 精品视频一区在线观看| 亚洲综合国产一区二区三区| 啦啦啦网站在线观看a毛片| 久久久精品国产SM调教网站| 久久成人18免费| 亚洲水蜜桃久久综合网站| 欧美人与性动交a欧美精品| 国产男女XX00免费观看| 国产第一福利影院| 五月婷婷精品| 成人午夜网址|