MQTT 5.0發布訂閱模式怎么理解

本篇內容介紹了“MQTT 5.0發布訂閱模式怎么理解”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

發布訂閱模式

發布訂閱模式區別于傳統的客戶端-服務器模式，它使發送消息的客戶端（發布者）與接收消息的客戶端（訂閱者）分離，發布者與訂閱者不需要建立直接聯系。我們既可以讓多個發布者向一個訂閱者發布消息，也可以讓多個訂閱者同時接收一個發布者的消息，它的精髓在于由一個被稱為代理的中間角色負責所有消息路由和分發的工作。傳統的客戶端-服務器模式可以實現類似的效果，但是無法做到像發布訂閱模式這樣簡潔和優雅。

發布訂閱模式的優點在于發布者與訂閱者的解耦，這種解耦表現在以下兩個方面：

• 空間解耦，訂閱者與發布者不需要建立直接連接，新的訂閱者想要加入網絡時不需要修改發布者的行為。

• 時間解耦，訂閱者和發布者不需要同時在線，即便不存在訂閱者也不影響發布者發布消息。

消息路由

代理作為發布訂閱模式的關鍵角色，它需要準確、高效地向訂閱者轉發其期望的消息，一般來說，比較常用的有以下兩種方式：

• 根據主題。訂閱者向代理訂閱自己感興趣的主題，發布者發布的所有消息中都會包含自己的主題，代理根據消息的主題判斷需要將消息轉發給哪些訂閱者。

• 根據消息內容。訂閱者定義其感興趣的消息的條件，只有當消息的屬性或內容滿足訂閱者定義的條件時，消息才會被投遞到該訂閱者。嚴格來講，主題也可以算是消息內容的一種。

發布訂閱模式的松耦合特性，也帶來了一些副作用。由于發布者并不知曉訂閱者的狀態，因此發布者也無法得知訂閱者是否收到了消息，或者是否正確處理了消息。這種情況下，想要保障交付往往需要更多的消息交互流程，例如，訂閱者收到消息后向某個主題發送應答，發布者此時轉變為訂閱者等待應答。

MQTT

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

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

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

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

“MQTT 5.0發布訂閱模式怎么理解”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！