簡介：本文整理了一份IoT佇列的干貨知識，讓物聯網從業者更進一步了解IoT場景佇列，一同探討一個適合于物聯網系統的訊息佇列，
傳統的訊息佇列（（Kafka、RocketMQ等）經過多年打磨，在高性能、海量堆積、訊息可靠性等諸多方面都已經做得非常極致，但在物聯網場景中，往往需要面臨著海量的訊息傳遞，傳統的訊息隊串列現的“力不從心”，
IoT領域中，從應用服務器到嵌入式芯片，都需要傳遞事件訊息，比如共享充電寶的開柜子、開燈指令從服務器發到設備、工業網關高頻訊息流等，在這些資訊傳遞的程序中，佇列最大意義在于讓整個訊息事件在不可控的環境因素變成一個平穩運行的系統，因為IoT設備時不時會由于故障或網路抖動會導致大量訊息洪峰，
阿里云AIoT作為物聯網領域的引領者和創新者，在訊息佇列領域不斷深耕與沉淀，為了讓物聯網從業者更進一步了解IoT場景佇列，阿里云技術專家呂建文，整理了一份IoT佇列的干貨知識，與大家一同探討一個適合于物聯網系統的訊息佇列，
一、IoT佇列和普通佇列的差異點
1，上下行隔離拆分
在IoT場景中，我們把需要佇列分為兩個場景，一個是上行佇列，一個是下行佇列， 拆分之后，可以隔離上下行鏈路，控制一個設備，比如支付成功要下發打開柜子等，上行出任何問題，千萬不能影響到下行業務，另外，上下行兩條鏈路的特點差異非常大，設備上行訊息，并發量非常高，但很多場景下對于可靠性和時延要求低，而設備下行訊息，并發量則比較低，但下行訊息（一般是控制設備指令）要求到達成功率很高，
2，支持設備級的海量topic
傳統佇列的核心訴求是，不論堆積多少不影響它的性能，kafka的topic一多，原本訊息順序寫檔案優勢就會導致一個broker要退化到隨機寫，失去優勢，另外要zookeeper來協調這么多topic也是有局限，所以這些佇列本身有提供一個外掛代理橋接器對外入口是多個設備topic，再橋接映射到少量的實際kafka topic，這方案有一定可行性，但做不到隔離效果，治標不治本，
通過，圖1和圖2對比較明顯，一個佇列擁塞盡量減少對其它設備影響，我們需要的是“海量topic盡量相互隔離，并且不影響整體性能”，盡量做到設備A的訊息堆積topic，不影響設備B，
3，實時生成訊息優先發送
先舉一個例子，一個快遞柜業務的佇列堆積，然后“此時此刻”在柜子旁邊的用戶死命的在旁邊用手機點開柜子怎么也打不開（此時后端系統都恢復了），問題就是佇列里面還有幾十萬條的訊息，新來的訊息需要排隊, 等著之前的那些訊息消費完，甭管這些訊息還有沒有用， 因此，實時生成訊息優先發送，堆積的訊息進入降級模式，
二、IoT訊息佇列誕生
1， IoT佇列的設計思路
設計目標是為了打造一個支持上下行隔離、實時優先、及海量topic的佇列網關，設計原則如下：
- 完全follow開源生態、和傳統佇列互補兼容
- 保序降級，實時優先，堆積退化；僅實時訊息相對有序，
- 海量topic，多租戶隔離
- 連接、計算、存盤分離
2， 訊息模式
圖片只是個片段，從這個模式可以看出來機制差別，大家都沒有錯，只是出發點不同，
3， 連接、計算、存盤分離
broker不做連接，連接網關代理，broker只做流轉分發，無狀態+水平擴展；存盤交給nosql DB，高吞吐寫，
4， 訊息策略-推拉結合
這個應該是佇列的核心難點之一，和傳統佇列區分在于，我們考慮為平臺化模式，獨享資源過于昂貴，但帶來問題是消費端不可控，所以使用結合模式，只有在消費者在線時會拉取堆積訊息，而拉取是由AMQP佇列網關來做，給到用戶介面始終是推送過去的onMessage回呼，
- broker不是直接讓consumer來連接，而是把佇列網關剝離出來， 這樣會更靈活，甚至對于部分用戶我們的queue可以切換到ons、kafka等實作，kafka、rocketmq做法是在連接時會分配給客戶端一個broker接入地址，
- broker實時訊息優先推送給consumer，失敗才會落到queue ；這是一個完整事件，如果沒有完成則不給producer commit，
- 異步ACK
5， 線性擴展-離線訊息部分
實時部分訊息采用推方式，基本上不會成為瓶頸，消費不過來訊息進入堆積模式，由于底層依賴存盤已經幫我們解決核心存盤的擴展，剩下主要問題點在于如何消除寫入熱點和消費熱點，這樣broker可以完全做到無狀態，
三，一個思考——如何解決海量topic問題？
首先面對“大量”的問題一般都是考慮磁區，單元化，分組等隔離和拆分，這里海量topic我們討論針對一個單實體模式下如何盡可能做到更多topic，完全任意數量都能100%沒問題肯定是不現實的，
由于broker和存盤已經隔離，broker和topic已經沒有什么關系，或者說任何topic資料生成，broker做的事情就是寫入和分發，
- 海量topic，每個topic有限數量訂閱： topic和訂閱者關系使用redis快取或本地快取，針對mqtt topic匹配有個topic tree的樹演算法，hivemq有實作版本，
- 單個topic 海量訂閱： 這個場景其實是組播和廣播，我們不會考慮在佇列本身上面去做這個事情，而是在上層封裝廣播組件來協調任務和批量發送，
四， 阿里云AIoT訊息佇列
目前阿里云AIoT佇列，也叫服務端訂閱，意思就是用戶用服務端訂閱他們設備訊息，為了降低接入成本，用戶可以使用AMQP1.0協議接入，符合開源生態， 同時兼容傳統佇列和新佇列，交給用戶按場景來選擇，用戶即可選擇使用kafka、mq，也可以選用iot佇列，甚至組合模式，比如按訊息特征規則來配置流轉佇列，
阿里云AIoT的場景佇列實踐，在現有mq佇列、kafka佇列融合之外，加了種自有的實時優先佇列實作，同時，加入了佇列網關代理，既能讓用戶選擇普通訊息佇列，也可以選擇輕便的IoT訊息佇列，
原文鏈接：https://developer.aliyun.com/article/785685?
著作權宣告：本文內容由阿里云實名注冊用戶自發貢獻，著作權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任，具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》，如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻洗掉涉嫌侵權內容，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/293132.html
標籤：其他