IoT裝置訊息洪峰怎麼扛？ 阿里雲AIoT訊息佇列深度解讀

傳統的訊息佇列（（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訊息佇列。