阿里云代理商:IoT設備消息洪峰怎么扛？ 阿里云AIoT消息隊列深度解讀

　　傳統(tǒng)的消息隊列（（Kafka、RocketMQ等）經(jīng)過多年打磨，在高性能、海量堆積、消息可靠性等諸多方面都已經(jīng)做得非常極致，但在物聯(lián)網(wǎng)場景中，往往需要面臨著海量的消息傳遞，傳統(tǒng)的消息隊列表現(xiàn)的“力不從心”。

　　IoT領域中，從應用服務器到嵌入式芯片，都需要傳遞事件消息，比如共享充電寶的開柜子、開燈指令從服務器發(fā)到設備、工業(yè)網(wǎng)關(guān)高頻消息流等，在這些信息傳遞的過程中，隊列最大意義在于讓整個消息事件在不可控的環(huán)境因素變成一個平穩(wěn)運行的系統(tǒng)，因為IoT設備時不時會由于故障或網(wǎng)絡抖動會導致大量消息洪峰。

　　阿里云AIoT作為物聯(lián)網(wǎng)領域的引領者和創(chuàng)新者，在消息隊列領域不斷深耕與沉淀，為了讓物聯(lián)網(wǎng)從業(yè)者更進一步了解IoT場景隊列，阿里云技術(shù)專家呂建文，整理了一份IoT隊列的干貨知識，與大家一同探討一個適合于物聯(lián)網(wǎng)系統(tǒng)的消息隊列。

　　一、IoT隊列和普通隊列的差異點

　　1，上下行隔離拆分

　　在IoT場景中，我們把需要隊列分為兩個場景，一個是上行隊列，一個是下行隊列。 拆分之后，可以隔離上下行鏈路，控制一個設備，比如支付成功要下發(fā)打開柜子等，上行出任何問題，千萬不能影響到下行業(yè)務。另外，上下行兩條鏈路的特點差異非常大。設備上行消息，并發(fā)量非常高，但很多場景下對于可靠性和時延要求低，而設備下行消息，并發(fā)量則比較低，但下行消息（一般是控制設備指令）要求到達成功率很高。

　　2，支持設備級的海量topic

　　傳統(tǒng)隊列的核心訴求是，不論堆積多少不影響它的性能。kafka的topic一多，原本消息順序?qū)懳募?yōu)勢就會導致一個broker要退化到隨機寫，失去優(yōu)勢，另外要zookeeper來協(xié)調(diào)這么多topic也是有局限，所以這些隊列本身有提供一個外掛代理橋接器對外入口是多個設備topic，再橋接映射到少量的實際kafka topic，這方案有一定可行性，但做不到隔離效果，治標不治本。

　　通過，圖1和圖2對比較明顯，一個隊列擁塞盡量減少對其它設備影響。我們需要的是“海量topic盡量相互隔離，并且不影響整體性能”，盡量做到設備A的消息堆積topic，不影響設備B。

　　3，實時生成消息優(yōu)先發(fā)送

　　先舉一個例子，一個快遞柜業(yè)務的隊列堆積，然后“此時此刻”在柜子旁邊的用戶死命的在旁邊用手機點開柜子怎么也打不開（此時后端系統(tǒng)都恢復了），問題就是隊列里面還有幾十萬條的消息，新來的消息需要排隊, 等著之前的那些消息消費完，甭管這些消息還有沒有用。  因此，實時生成消息優(yōu)先發(fā)送，堆積的消息進入降級模式。

　　二、IoT消息隊列誕生

　　1， IoT隊列的設計思路

　　設計目標是為了打造一個支持上下行隔離、實時優(yōu)先、及海量topic的隊列網(wǎng)關(guān)，設計原則如下：

　　完全follow開源生態(tài)、和傳統(tǒng)隊列互補兼容

　　保序降級，實時優(yōu)先，堆積退化；僅實時消息相對有序。

　　海量topic，多租戶隔離

　　連接、計算、存儲分離

　　2， 消息模式

　　圖片只是個片段，從這個模式可以看出來機制差別，大家都沒有錯，只是出發(fā)點不同。

　　3， 連接、計算、存儲分離

　　broker不做連接，連接網(wǎng)關(guān)代理，broker只做流轉(zhuǎn)分發(fā)，無狀態(tài)+水平擴展；存儲交給nosql DB，高吞吐寫。

　　4， 消息策略-推拉結(jié)合

　　這個應該是隊列的核心難點之一，和傳統(tǒng)隊列區(qū)分在于，我們考慮為平臺化模式，獨享資源過于昂貴。但帶來問題是消費端不可控，所以使用結(jié)合模式，只有在消費者在線時會拉取堆積消息，而拉取是由AMQP隊列網(wǎng)關(guān)來做，給到用戶接口始終是推送過去的onMessage回調(diào)。

　　broker不是直接讓consumer來連接，而是把隊列網(wǎng)關(guān)剝離出來，  這樣會更靈活，甚至對于部分用戶我們的queue可以切換到ons、kafka等實現(xiàn)。kafka、rocketmq做法是在連接時會分配給客戶端一個broker接入地址。

　　broker實時消息優(yōu)先推送給consumer，失敗才會落到queue ；這是一個完整事件，如果沒有完成則不給producer commit。

　　異步ACK

　　5， 線性擴展-離線消息部分

　　實時部分消息采用推方式，基本上不會成為瓶頸，消費不過來消息進入堆積模式。由于底層依賴存儲已經(jīng)幫我們解決核心存儲的擴展，剩下主要問題點在于如何消除寫入熱點和消費熱點，這樣broker可以完全做到無狀態(tài)。

　　三，一個思考——如何解決海量topic問題？

　　首先面對“大量”的問題一般都是考慮分區(qū)，單元化，分組等隔離和拆分，這里海量topic我們討論針對一個單實例模式下如何盡可能做到更多topic，完全任意數(shù)量都能100%沒問題肯定是不現(xiàn)實的。

　　由于broker和存儲已經(jīng)隔離，broker和topic已經(jīng)沒有什么關(guān)系，或者說任何topic數(shù)據(jù)生成，broker做的事情就是寫入和分發(fā)。

　　海量topic，每個topic有限數(shù)量訂閱：  topic和訂閱者關(guān)系使用redis緩存或本地緩存，針對mqtt topic匹配有個topic tree的樹算法，hivemq有實現(xiàn)版本。

　　單個topic 海量訂閱：  這個場景其實是組播和廣播，我們不會考慮在隊列本身上面去做這個事情，而是在上層封裝廣播組件來協(xié)調(diào)任務和批量發(fā)送。

　　四， 阿里云AIoT消息隊列

　　目前阿里云AIoT隊列，也叫服務端訂閱，意思就是用戶用服務端訂閱他們設備消息。為了降低接入成本，用戶可以使用AMQP1.0協(xié)議接入，符合開源生態(tài)。 同時兼容傳統(tǒng)隊列和新隊列，交給用戶按場景來選擇，用戶即可選擇使用kafka、mq，也可以選用iot隊列，甚至組合模式，比如按消息特征規(guī)則來配置流轉(zhuǎn)隊列。

　　阿里云AIoT的場景隊列實踐，在現(xiàn)有mq隊列、kafka隊列融合之外，加了種自有的實時優(yōu)先隊列實現(xiàn)，同時，加入了隊列網(wǎng)關(guān)代理，既能讓用戶選擇普通消息隊列，也可以選擇輕便的IoT消息隊列。

　　阿里云代理商：

　　聚搜云

　　上海聚搜信息技術(shù)有限公司

　　阿里云代理商網(wǎng)站：http://m.gzjcsc123.com/

　　阿里云代理商云店：https://partner.aliyun.com/shop/1690271921397837

　　阿里云優(yōu)惠券鏈接：http://aliyun.jusoucn.com/

　　Q/V :582059487    TEL：150-2661-2550