RocketMQ MQTT 概覽

傳統訊息佇列 MQ 主要用於服務（端點）之間的訊息傳遞，例如電子商務領域的交易訊息、支付訊息、物流訊息等。然而，在訊息的總類別中，還有一個非常重要且常見的訊息領域，即 IoT 終端裝置訊息。近年來，我們看到來自智慧家庭和工業互聯的 IoT 裝置導向新聞爆炸性成長，而發展十幾年的行動網際網路行動 APP 端新聞，數量級仍舊龐大。終端裝置的訊息數量級比傳統伺服器大好幾個數量級，且仍在快速成長中。

如果有一個統一的訊息系統（產品）來提供多場景運算（例如串流、事件）和多場景（IoT、APP）存取，其實是非常有價值的，因為訊息也是重要的資料。只有一個系統，可以將儲存成本降到最低，並有效避免不同系統間資料同步造成的資料一致性問題與挑戰。

基於此，我們引入了 RocketMQ-MQTT 擴充套件專案，來實現 RocketMQ 統一存取 IoT 裝置和伺服器的訊息，並提供整合的訊息儲存和互通能力。

MQTT 協定

在 IoT 終端場景中，MQTT 協定目前在業界被廣泛使用，它是一個源於物聯網 IoT 場景的標準開放協定，由 OASIS 聯盟定義。由於 IoT 設備種類繁多，運作環境各異，一個標準的接入協定就顯得尤為關鍵。

MQTT 協定定義了一種 Pub/Sub 通訊模式，與 RocketMQ 類似，但在訂閱方式上更為靈活，可以支援多層級 Topic 訂閱（例如「/t/t1/t2」），甚至可以支援萬用字元訂閱（例如「/t/t1/+」）。

模型介紹

佇列儲存模型

我們設計了一個多維度分發的 Topic 佇列模型，如上圖所示，訊息可以來自各種接入場景（例如伺服器端的 MQ/AMQP、客戶端的 MQTT），但只會寫入並儲存在 commitlog 中一份，然後再分發到多個需求場景的佇列索引（ConsumerQueue）中。例如，伺服器端場景（MQ/AMQP）可以按照一級 Topic 佇列進行傳統的伺服器端消費，客戶端 MQTT 場景則可以按照 MQTT 多層級 Topic 和萬用字元訂閱進行消費。

這樣的佇列模型可以同時支援伺服器端和終端場景的接入、訊息收發，達到整合的目的。

推拉模型

上圖展示了一個推拉模型，圖中的 P 節點是一個協定閘道或 Broker 插件，終端設備通過 MQTT 協定連接到閘道節點。訊息可以來自各種場景（MQ/AMQP/MQTT），在儲存在 Topic 佇列後，會有一個 Notify 邏輯模組實時感知到新訊息的到來，然後會產生一個訊息事件（即訊息的 Topic 名稱），該事件會被推送到閘道節點，閘道節點根據已連接終端設備的訂閱狀態進行內部匹配，找出哪些終端設備可以匹配，然後向儲存層觸發一個拉取請求，讀取訊息並推送到終端設備。

架構概覽

我們的目標是基於 RocketMQ 達成一個整合且自封閉的迴圈，但我們不希望 Broker 被入侵到更多場景邏輯中。我們抽象一個協定運算層，它可以是一個閘道器或一個代理外掛程式。Broker 專注於解決佇列問題，並對佇列儲存進行一些調整或轉換，以滿足上述運算需求。協定運算層負責協定存取，並且必須是可插入和部署的。