MQTT Part 1
- 後面還有幾個part講詳細的介紹
we’ll explore the basic concepts (
publish/subscribe, client/broker
) and basic functionality (
Connect, Publish, Subscribe
) of MQTT. Then, we’ll look at the features:
Quality of Service, Retained Messages, Persistent Session, Last Will and Testament, Keep Alive and more
.
MQTT 簡介
“MQTT 是用戶端伺服器釋出/訂閱消息傳輸協定。它重量輕、開放、簡單，并且設計得易于實施。這些特性使其非常适合在許多情況下使用，包括受限環境，例如在機器對機器 (M2M) 和物聯網 (IoT) 環境中需要少量代碼占用空間和/或網絡帶寬非常寶貴的環境中的通信。 “
引用自官方MQTT 3.1.1 規範
值得注意的是，許多來源錯誤地将 MQTT 标記為消息隊列協定。MQTT 不是傳統的消息排隊解決方案（盡管在某些情況下可以對消息進行排隊，我們将在即将釋出的文章中詳細讨論這一事實）
pub/sub
The publish/subscribe pattern 提供了傳統用戶端-伺服器架構的替代方案。在用戶端-伺服器模型中，用戶端直接與端點通信。釋出/訂閱模型decouples publisher from subscribers(完成釋出者和訂閱者的解耦)
– 它們之間的連接配接由第三個元件處理( broker)
pub/sub 最重要的方面是消息的釋出者與接收者（訂閱者）的解耦。這種解耦有幾個次元：
- 空間解耦：釋出者和訂閱者不需要互相了解（例如，不交換 IP 位址和端口）。
- 時間解耦：釋出者和訂閱者不需要同時運作。
-
同步解耦：兩個元件的操作在釋出或接收時不需要中斷。
總之，釋出/訂閱模型消除了消息釋出者和接收者/訂閱者之間的直接通信。代理的過濾活動可以控制哪個用戶端/訂閱者接收哪個消息。解耦包括三個次元：空間、時間和同步。
消息過濾
很明顯，broker 在 pub/sub 過程中起着舉足輕重的作用。但是代理如何過濾所有消息，以便每個訂閱者隻接收感興趣的消息？正如您将看到的，經紀人有幾個過濾選項：
-
選項 1：基于主題的過濾
此過濾基于屬于每條消息的主題topic。接收用戶端向代理訂閱感興趣的主題。從那時起，代理確定接收用戶端擷取所有釋出到訂閱主題的消息。通常，主題是具有分層結構的字元串，允許基于有限數量的表達式進行過濾。
-
選項 2：基于内容的過濾
在基于内容的過濾中，代理根據特定的内容過濾語言過濾消息。接收用戶端訂閱過濾他們感興趣的消息查詢。這種方法的一個顯着缺點是必須事先知道消息的内容，不能加密或輕易更改。
-
選項 3：基于類型的過濾
當使用面向對象的語言時，基于消息（事件）的類型/類進行過濾是一種常見做法。例如，訂閱者可以收聽所有類型為 Exception 或任何子類型的消息。
當然，釋出/訂閱并不是每個用例的答案。在使用此模型之前，您需要考慮一些事項。釋出者和訂閱者的解耦是 pub/sub 的關鍵，它本身也存在一些挑戰。例如，
您需要事先了解已釋出資料的結構
。對于基于主題的過濾，釋出者和訂閱者都需要知道要使用哪些主題。要記住的另一件事是消息傳遞。釋出者不能假設有人正在收聽發送的消息。在某些情況下，可能沒有訂閱者讀取特定消息。
MQTT
既然我們已經大緻探讨了釋出/訂閱模型，讓我們專門關注MQTT。根據您想要實作的目标，
MQTT 展現了我們提到的 pub/sub 的所有方面
：
MQTT 在空間上分離了釋出者和訂閱者。要釋出或接收消息，釋出者和訂閱者隻需要知道代理的主機名/IP 和端口。
MQTT 按時間解耦。盡管大多數 MQTT 用例都近乎實時地傳遞消息，但如果需要，代理可以為不線上的用戶端存儲消息。（必須滿足兩個條件才能存儲消息：用戶端已連接配接到持久會話并訂閱了
Quality of Service
大于 0 的主題）
MQTT 異步工作。由于大多數用戶端庫異步工作并且基于回調或類似模型，是以在等待消息或釋出消息時不會阻塞任務。在某些用例中，同步是可取的，也是可能的。為了等待某個消息，一些庫具有同步 API。但流程通常是異步的。
另一件應該提到的事情是MQTT在用戶端特别容易使用。大多數釋出/訂閱系統都有代理端的邏輯，但在使用用戶端庫時，MQTT 确實是釋出/訂閱的本質，這使其成為适用于小型和受限裝置的輕量級協定。
MQTT 使用subject-based filtering of messages。每條消息都包含一個topic（subject），代理可以使用它來确定訂閱用戶端是否收到消息。
為了應對釋出/訂閱系統的挑戰，MQTT 具有三個服務品質 (QoS) 級别。您可以輕松指定消息從用戶端成功傳送到代理或從代理成功傳送到用戶端。但是，有可能沒有人訂閱特定主題。如果這是一個問題，the broker必須知道如何處理這種情況
與消息隊列的差別
消息隊列存儲消息直到消息被消費
，每條傳入消息都存儲在隊列中，直到被用戶端（通常稱為消費者）接收。如果沒有用戶端接收到消息，消息将保持在隊列中并等待被消費。在消息隊列中，消息不可能不被任何用戶端處理
一條消息隻被一個用戶端消費
,在傳統的消息隊列中，一條消息隻能被一個消費者處理。負載分布在隊列的所有消費者之間。在 MQTT 中，行為完全相反：訂閱主題的每個訂閱者都會收到消息。
隊列是命名的，必須顯式建立 。隊列比主題嚴格得多。在使用隊列之前，必須使用單獨的指令顯式建立隊列。隻有在隊列命名和建立之後，才可以釋出或消費消息。相比之下，MQTT 主題非常靈活，可以即時建立。
