MQTT發(fā)布/訂閱有哪幾個維度

這篇文章主要講解了“MQTT發(fā)布/訂閱有哪幾個維度”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“MQTT發(fā)布/訂閱有哪幾個維度”吧！

發(fā)布/訂閱模式

發(fā)布/訂閱（Pub/Sub）對于傳統(tǒng)的客戶端-服務(wù)器（C/S）模式，提供了另一種選擇。在客戶端-服務(wù)器模式中，客戶端直接與一個服務(wù)端點通信。而在發(fā)布/訂閱模式解偶了兩種客戶端，一種是稱為發(fā)布者發(fā)送消息的客戶端，一種是稱為訂閱者接收消息的客戶端。發(fā)布者和訂閱者不會直接聯(lián)系，實際上他們不知道彼此是否存在，他們之間的連接是通過一個第三者組件，稱為消息代理（Broker）。消息代理的工作是過濾所有進來的消息，然后正確地分發(fā)到訂閱者。

MQTT發(fā)布/訂閱

發(fā)布/訂閱最重要的一面是解偶了消息的發(fā)布者和接收（訂閱者），這個解偶有幾個維度：

• 空間解偶： 發(fā)布者和訂閱者不需要知道彼此（例如沒有IP地址和端口的交換）。

• 時間解偶： 發(fā)布者和訂閱者不需要同時運行。

• 同步解偶： 在發(fā)布或接收的期間，不需要終端兩者上的操作。

綜上所述，發(fā)布/訂閱模式移除了消息的發(fā)布者和接收者/訂閱者之間的直接連接。消息代理的過濾行為是的它可以控制哪個客戶端/訂閱者接收到哪個消息。解偶有三個維度：空間，時間和同步。

可擴展性

發(fā)布/訂閱模式比傳統(tǒng)的客戶端-服務(wù)器方法更好擴展。因為消息代理上的操作可以高度并行化，并且消息可以事件驅(qū)動的方式處理。消息緩存以及消息的智能路由通常是提供可擴展性的決定性因素。盡管如此，擴展到百萬的連接是一個挑戰(zhàn)。如此高級別的連接數(shù)可以通過消息代理節(jié)點集群來完成，集群通過負(fù)載均衡器將負(fù)載分布到更多的單獨服務(wù)器上（這個主題超出了當(dāng)前文章的范圍，我們將在另外的文件中來討論）。

消息過濾

很顯然，消息代理在發(fā)布/訂閱的過程中充當(dāng)著重要的角色。那消息是如何過濾所有消息，以使得每個訂閱者只接收到感興趣的消息的呢？如你所見，消息代理有以下幾個過濾選項：

選項一： 基于主題過濾

該過濾基于每個消息的主題。接收客戶端向消息代理訂閱其感興趣的主題，然后消息代理確保接收客戶端獲得所有發(fā)布到該主題的消息。通常，主題是具有層級結(jié)構(gòu)的字符串，允許基于有限數(shù)量的表達式進行過濾。

選項二： 基于內(nèi)容過濾

基于內(nèi)容過濾中，消息代理基于一個特定的內(nèi)容過濾語言來過濾消息。接收客戶端向消息代理訂閱他們感興趣的過濾查詢。這個方法的一個重要確定是必須事先知道消息的內(nèi)容，以及消息不能被加密或容易修改。

選項三： 基于類型過濾

當(dāng)使用面向?qū)ο蟮恼Z言，基于消息（事件）的類型/類別的過濾是常見的做法。例如，一個訂閱者可以監(jiān)聽異常類型或者任意子類型的所有消息。

當(dāng)然，發(fā)布/訂閱也不是每種用例的答案，在你使用這個模型之前，你需要考慮一些事情。發(fā)布者和訂閱者的解偶是發(fā)布/訂閱的關(guān)鍵，它本身就是一個挑戰(zhàn)。例如，你需要事先知道發(fā)布的數(shù)據(jù)結(jié)構(gòu)是什么樣。對于基于主題的過濾，發(fā)布者和訂閱者都需要知道使用哪個主題。另一個需要記住的是消息傳遞，發(fā)布者不能假設(shè)某人在正監(jiān)聽它發(fā)送的消息。在一些情況下，可能沒有訂閱者讀取特定的消息。

MQTT

我們大體上探索了發(fā)布/訂閱模式，現(xiàn)在讓我們專注于MQTT。取決于你想要完成什么，MQTT體現(xiàn)了我們提到的發(fā)布/訂閱的所有方面：

• MQTT空間上解偶了發(fā)布者和訂閱者。要分發(fā)或者接收消息，發(fā)布者和訂閱者僅僅需要知道消息代理服務(wù)的主機名/IP地址以及端口。

• MQTT通過時間解偶。雖然大部分MQTT用例都會近實時地傳遞消息，但如果需要，消息代理可以為不在線的客戶端存儲消息。（要存儲消息，兩個條件必須滿足： 客戶端以持久會進行連接的，以及訂閱的主題服務(wù)質(zhì)量大于0）。

• MQTT以異步工作。因為大部分客戶端庫都是以異步工作，以及基于回調(diào)或者相似的模型，當(dāng)?shù)却⒒蛘甙l(fā)布消息時，任務(wù)不會被阻塞。在某些使用情況，同步也是需要和可取的，為了等待某個消息，一些庫具有同步的API。但是流程通常是異步的。

應(yīng)該提到的另一件事情是MQTT特別容易在客戶端使用。大部分發(fā)布/訂閱系統(tǒng)都有消息代理端的邏輯，但是當(dāng)使用客戶端庫時，MQTT確實是發(fā)布/訂閱的本質(zhì)，這使得它成為小型和受限制設(shè)備的輕量級協(xié)議。

當(dāng)MQTT使用基于主題的消息過濾時，每條消息都含有一個主題，消息代理使用主題來決定訂閱的客戶端是否收到消息。請閱讀第五部分學(xué)習(xí)更多關(guān)于主題的概念。如果需要，也可以通過HiveMQ MQTT消息代理和我們的自定義插件系統(tǒng)來設(shè)置基于內(nèi)容的過濾。

為了應(yīng)對發(fā)布/訂閱系統(tǒng)的挑戰(zhàn)，MQTT具有服務(wù)質(zhì)量級別（QoS）。你可以輕松制定消息從客戶端成功傳遞到代理或者從代理傳遞到客戶端，但是也有可能沒有人訂閱到特定的主題。如果這是一個問題，這取決于消息代理如何處理這樣的情況。例如，HiveMQ的MQTT代理具有插件系統(tǒng)，它可以識別這樣的情況。你可以讓代理執(zhí)行操作，或者簡單地將每條消息記錄到數(shù)據(jù)以進行歷史分析。為了保持層級主題數(shù)的靈活性，非常仔細(xì)地設(shè)計主題樹并為了將來的用例保留空間是很重要的。如果你遵循這些策略，MQTT非常適合生產(chǎn)設(shè)置。

與消息隊列的區(qū)別

對于MQTT的名稱和協(xié)議是否實現(xiàn)了一個消息隊列，存在這混淆，我們將嘗試闡明該主題并解釋其中的差異。在上一篇文章中，我們提到了MQTT是參考了來自IBM的MQ系列產(chǎn)品，與“消息隊列”無關(guān)。不管這個名字是來自哪里，理解MQTT和傳統(tǒng)的消息隊列之間的差異是有用的：

消息隊列存儲消息，直到這些消息被消費 - 當(dāng)你使用消息隊列，沒一個進入的消息都被存儲在一個隊列里，直到消息被一個客戶端（通常稱為一個消費者）取走。在消息隊列中，任何客戶端都不可能處理消息，就像在MQTT中如果沒有人訂閱一個主題。

一個消息只可以被一個客戶端消費 - 另一個大不同是，在傳統(tǒng)的消息隊列中，一個消息只能被一個消費者處理。負(fù)載在隊列的所有消費者之間分配，在MQTT中行為恰好相反，每個訂閱相同主題的訂閱著都會得到消息。

隊列是命名的，且必須明確創(chuàng)建 - 一個隊列要比主題嚴(yán)格得多。在一個隊列可以被使用前，必須使用單獨的命令顯式地創(chuàng)建隊列。只有在隊列被命名和創(chuàng)建之后，才可能發(fā)布或者消費消息。相反，MQTT的主題非常靈活，可以即時創(chuàng)建。

感謝各位的閱讀，以上就是“MQTT發(fā)布/訂閱有哪幾個維度”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對MQTT發(fā)布/訂閱有哪幾個維度這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！