本篇內容介紹了“MQTT 5.0發(fā)布訂閱模式怎么理解”的有關知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠學有所成!
創(chuàng)新互聯建站是一家專業(yè)提供陽城企業(yè)網站建設,專注與網站建設、網站設計、H5技術、小程序制作等業(yè)務。10年已為陽城眾多企業(yè)、政府機構等服務。創(chuàng)新互聯專業(yè)的建站公司優(yōu)惠進行中。
發(fā)布訂閱模式區(qū)別于傳統的客戶端-服務器模式,它使發(fā)送消息的客戶端(發(fā)布者)與接收消息的客戶端(訂閱者)分離,發(fā)布者與訂閱者不需要建立直接聯系。我們既可以讓多個發(fā)布者向一個訂閱者發(fā)布消息,也可以讓多個訂閱者同時接收一個發(fā)布者的消息,它的精髓在于由一個被稱為代理的中間角色負責所有消息路由和分發(fā)的工作。傳統的客戶端-服務器模式可以實現類似的效果,但是無法做到像發(fā)布訂閱模式這樣簡潔和優(yōu)雅。
發(fā)布訂閱模式的優(yōu)點在于發(fā)布者與訂閱者的解耦,這種解耦表現在以下兩個方面:
空間解耦,訂閱者與發(fā)布者不需要建立直接連接,新的訂閱者想要加入網絡時不需要修改發(fā)布者的行為。
時間解耦,訂閱者和發(fā)布者不需要同時在線,即便不存在訂閱者也不影響發(fā)布者發(fā)布消息。
代理作為發(fā)布訂閱模式的關鍵角色,它需要準確、高效地向訂閱者轉發(fā)其期望的消息,一般來說,比較常用的有以下兩種方式:
根據主題。訂閱者向代理訂閱自己感興趣的主題,發(fā)布者發(fā)布的所有消息中都會包含自己的主題,代理根據消息的主題判斷需要將消息轉發(fā)給哪些訂閱者。
根據消息內容。訂閱者定義其感興趣的消息的條件,只有當消息的屬性或內容滿足訂閱者定義的條件時,消息才會被投遞到該訂閱者。嚴格來講,主題也可以算是消息內容的一種。
發(fā)布訂閱模式的松耦合特性,也帶來了一些副作用。由于發(fā)布者并不知曉訂閱者的狀態(tài),因此發(fā)布者也無法得知訂閱者是否收到了消息,或者是否正確處理了消息。這種情況下,想要保障交付往往需要更多的消息交互流程,例如,訂閱者收到消息后向某個主題發(fā)送應答,發(fā)布者此時轉變?yōu)橛嗛喺叩却龖稹?/p>
MQTT 協議根據主題而不是消息內容來分發(fā)消息,每個消息都包含一個主題,代理無需解析用戶數據,這為實現一個通用的、與業(yè)務無關的 MQTT 代理提供了可能。用戶也可以隨意對自己的數據進行加密,這對于廣域網通信是非常有用的。
MQTT 主題中可以有多個層級,并且允許對一個或多個層級進行模糊匹配,使客戶端能夠一次性訂閱多個主題。關于 MQTT 主題的詳細特性,我們會在后續(xù)的文章中專門進行介紹。
與消息隊列相比,MQTT 并不要求發(fā)布或者訂閱之前顯式地創(chuàng)建主題,唯一可能造成的不良影響是客戶端可能使用錯誤的主題而不自知,但顯然靈活部署帶來的收益更高。
既然提到了消息隊列,那么正好解釋一下 MQTT 與消息隊列的區(qū)別。MQTT 并不是消息隊列,盡管兩者的很多行為和特性非常接近,比如都采用發(fā)布訂閱模式等,但是他們面向的場景有著顯著的不同。消息隊列主要用于服務端應用之間的消息存儲與轉發(fā),這類場景往往數據量大但接入量少,而 MQTT 面向的是 IoT 領域和移動互聯網領域,這類場景的側重點是海量的設備接入、管理與消息傳輸。在實際的場景中,兩者往往被結合起來使用,譬如先由 MQTT Broker 接收物聯網設備上傳的數據,然后通過消息隊列將這些數據轉發(fā)到具體應用進行處理。
“MQTT 5.0發(fā)布訂閱模式怎么理解”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注創(chuàng)新互聯網站,小編將為大家輸出更多高質量的實用文章!
分享標題:MQTT5.0發(fā)布訂閱模式怎么理解
當前鏈接:http://jinyejixie.com/article40/pdcgho.html
成都網站建設公司_創(chuàng)新互聯,為您提供面包屑導航、電子商務、全網營銷推廣、手機網站建設、網站制作、商城網站
聲明:本網站發(fā)布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源: 創(chuàng)新互聯