傳統的消息隊列（（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消息隊列。