MQTT 5.0 - 發佈訂閱模式介紹

MQTT 協議的核心在於發佈訂閱模式，在本文中，咱們將對這一模式進行深刻的介紹。

發佈訂閱模式

發佈訂閱模式區別於傳統的客戶端-服務器模式，它使發送消息的客戶端（發佈者）與接收消息的客戶端（訂閱者）分離，發佈者與訂閱者不須要創建直接聯繫。咱們既可讓多個發佈者向一個訂閱者發佈消息，也可讓多個訂閱者同時接收一個發佈者的消息，它的精髓在於由一個被稱爲代理的中間角色負責全部消息路由和分發的工做。傳統的客戶端-服務器模式能夠實現相似的效果，可是沒法作到像發佈訂閱模式這樣簡潔和優雅。

發佈訂閱模式的優勢在於發佈者與訂閱者的解耦，這種解耦表如今如下兩個方面：

• 空間解耦，訂閱者與發佈者不須要創建直接鏈接，新的訂閱者想要加入網絡時不須要修改發佈者的行爲。
• 時間解耦，訂閱者和發佈者不須要同時在線，即使不存在訂閱者也不影響發佈者發佈消息。

消息路由

代理做爲發佈訂閱模式的關鍵角色，它須要準確、高效地向訂閱者轉發其指望的消息，通常來講，比較經常使用的有如下兩種方式：

• 根據主題。訂閱者向代理訂閱本身感興趣的主題，發佈者發佈的全部消息中都會包含本身的主題，代理根據消息的主題判斷須要將消息轉發給哪些訂閱者。
• 根據消息內容。訂閱者定義其感興趣的消息的條件，只有當消息的屬性或內容知足訂閱者定義的條件時，消息纔會被投遞到該訂閱者。嚴格來說，主題也能夠算是消息內容的一種。

發佈訂閱模式的鬆耦合特性，也帶來了一些反作用。因爲發佈者並不知曉訂閱者的狀態，所以發佈者也沒法得知訂閱者是否收到了消息，或者是否正確處理了消息。這種狀況下，想要保障交付每每須要更多的消息交互流程，例如，訂閱者收到消息後向某個主題發送應答，發佈者此時轉變爲訂閱者等待應答。

MQTT

MQTT 協議根據主題而不是消息內容來分發消息，每一個消息都包含一個主題，代理無需解析用戶數據，這爲實現一個通用的、與業務無關的 MQTT 代理提供了可能。用戶也能夠隨意對本身的數據進行加密，這對於廣域網通訊是很是有用的。

MQTT 主題中能夠有多個層級，而且容許對一個或多個層級進行模糊匹配，使客戶端可以一次性訂閱多個主題。關於 MQTT 主題的詳細特性，咱們會在後續的文章中專門進行介紹。

與消息隊列相比，MQTT 並不要求發佈或者訂閱以前顯式地建立主題，惟一可能形成的不良影響是客戶端可能使用錯誤的主題而不自知，但顯然靈活部署帶來的收益更高。

既然提到了消息隊列，那麼正好解釋一下 MQTT 與消息隊列的區別。MQTT 並非消息隊列，儘管二者的不少行爲和特性很是接近，好比都採用發佈訂閱模式等，可是他們面向的場景有着顯著的不一樣。消息隊列主要用於服務端應用之間的消息存儲與轉發，這類場景每每數據量大但接入量少，而 MQTT 面向的是 IoT 領域和移動互聯網領域，這類場景的側重點是海量的設備接入、管理與消息傳輸。在實際的場景中，二者每每被結合起來使用，譬如先由 MQTT Broker 接收物聯網設備上傳的數據，而後經過消息隊列將這些數據轉發到具體應用進行處理。

但願經過這篇簡短的文章，您可以對發佈訂閱模式有一個直觀的瞭解。有關 MQTT 的其餘特性，咱們會在後續的文章中展開介紹。

---

更多信息請訪問咱們的官網 emqx.io，或關注咱們的開源項目 github.com/emqx/emqx ，詳細文檔請訪問 官方文檔。