一、MQTT 協(xié)議概念

MQTT 協(xié)議的全稱是 Message Queuing Telemetry Transport，翻譯為消息隊列傳輸探測，它是 ISO 標準下的一種基于發(fā)布 - 訂閱模式的消息協(xié)議，它是基于 TCP/IP 協(xié)議簇的，它是為了改善網(wǎng)絡(luò)設(shè)備硬件的性能和網(wǎng)絡(luò)的性能來設(shè)計的。MQTT 一般多用于 IoT 即物聯(lián)網(wǎng)上，廣泛應(yīng)用于工業(yè)級別的應(yīng)用場景，比如汽車、制造、石油、天然氣等。

在了解了?MQTT 的概念和應(yīng)用場景后，我們下來就來走進 MQTT 的學習中了，先來看一下 MQTT 有哪些概念。

?

二、MQTT 基礎(chǔ)

上面我們解釋了?MQTT 協(xié)議的基本概念，MQTT 協(xié)議總結(jié)一點就是一種輕量級的二進制協(xié)議，MQTT 協(xié)議與 HTTP 相比具有一個明顯的優(yōu)勢：數(shù)據(jù)包開銷較小，數(shù)據(jù)包開銷小就意味著更容易進行網(wǎng)絡(luò)傳輸。還有一個優(yōu)勢就是 MQTT 在客戶端容易實現(xiàn)，而且具有易用性，非常適合當今資源有限的設(shè)備。

你可能對這些概念有些諱莫如深，為什么具有?xxx 這種特性呢？這就需要從 MQTT 的設(shè)計說起了。

MQTT 協(xié)議由 Andy Stanford-Clark (IBM) 和 Arlen Nipper（Arcom，現(xiàn)為 Cirrus Link）于 1999 年發(fā)明。 他們需要一種通過衛(wèi)星連接石油管道的協(xié)議，以最大限度地減少電池損耗和帶寬。所以他們?yōu)檫@個協(xié)議規(guī)定了幾種要求：

1、這個協(xié)議必須易于實現(xiàn)；

2、這個協(xié)議中的數(shù)據(jù)必須易于傳輸，消耗成本?。?/p>

3、這個協(xié)議必須提供服務(wù)質(zhì)量管理；

4、這個協(xié)議必須支持連續(xù)的會話控制；

5、假設(shè)數(shù)據(jù)不可知，不強求傳輸數(shù)據(jù)的類型與格式，保持靈活性。

這些設(shè)計也是?MQTT 的精髓所在，MQTT 經(jīng)過不斷的發(fā)展，已經(jīng)成為了物聯(lián)網(wǎng) IoT 所必備的一種消息探測協(xié)議，官方強烈推薦使用的版本是 MQTT 5。

?

三、發(fā)布?- 訂閱模式

發(fā)布?- 訂閱模式，我相信接觸消息中間件架構(gòu)的同學都聽過，這是一種傳統(tǒng)的客戶端 - 服務(wù)器架構(gòu)的替代方案，因為一般傳統(tǒng)的客戶端-服務(wù)器是客戶端能夠直接和服務(wù)器進行通信。

但是發(fā)布?- 訂閱模式 pub/sub就不一樣了，發(fā)布訂閱模式會將發(fā)送消息的發(fā)布者 publisher與接收消息的訂閱者 subscribers進行分離，publisher 與 subscribers 并不會直接通信，他們甚至都不清楚對方是否存在，他們之間的交流由第三方組件 broker 代理。

pub/sub 最重要的方面是 publisher 與 subscriber 的解藕，這種耦合度有下面三個維度：

1、空間解耦

publisher 與 subscriber 并不知道對方的存在，例如不會有 IP 地址和端口的交互，也更不會有消息的交互。

2、時間解藕

publisher 與 subscriber 并不一定需要同時運行。

3、同步?Synchronization 解藕

兩個組件的操作比如 publish 和 subscribe 都不會在發(fā)布或者接收過程中產(chǎn)生中斷。

總之，發(fā)布/訂閱模式消除了傳統(tǒng)客戶-服務(wù)器之間的直接通信，把通信這個操作交給了 broker 進行代理，并在空間、時間、同步三個維度上進行了解藕。

?

四、可拓展性

pub/sub 比傳統(tǒng)的客戶端-服務(wù)器模式有了更好的拓展，這是由于 broker 的高度并行化，并且是基于事件驅(qū)動的模式?？赏卣剐赃€體現(xiàn)在消息的緩存和消息的智能路由，還可以通過集群代理來實現(xiàn)數(shù)百萬的連接，使用負載均衡器將負載分配到更多的單個服務(wù)器上，這就是 MQTT 的深度應(yīng)用了。

你可能不明白什么是事件驅(qū)動，我在這里解釋下事件驅(qū)動的概念。

事件驅(qū)動是一種編程范式，編程范式是軟件工程中的概念，它指的是一種編程方法或者說程序設(shè)計方式，比如說面向?qū)ο缶幊毯兔嫦蜻^程編程就是一種編程范式，事件驅(qū)動中的程序流程會由諸如用戶操作（點擊鼠標、鍵盤）、傳感器輸出或者從其他程序或傳遞的消息事件決定。事件驅(qū)動編程是圖形用戶界面和其他應(yīng)用程序比如?Web 中使用的主要范式，這些應(yīng)用程序能夠響應(yīng)用戶輸入執(zhí)行某些操作為中心，這同時也適用于驅(qū)動程序的編程。

?

五、消息過濾

在?pub/sub 的架構(gòu)模式中，broker 扮演著至關(guān)重要的作用，其中非常重要的一點就是 broker 能夠?qū)ο⑦M行過濾，使每個訂閱者只接收自己感興趣的消息。broker 有幾個可以過濾的選項：

1、基于主題的過濾

MQTT 是基于 subject 的消息過濾的，每條消息都會有一個 topic ，接收客戶端會向 borker 訂閱感興趣的 topic，訂閱后，broker 就會確保客戶端收到發(fā)布到 topic 中的消息。

2、基于內(nèi)容的過濾

在基于內(nèi)容的過濾中，broker 會根據(jù)特定的內(nèi)容過濾消息，接受客戶端會經(jīng)過過濾他們感興趣的內(nèi)容。這種方法的一個顯著的缺點就是必須事先知道消息的內(nèi)容，不能加密或者輕易修改。

3、基于類型的過濾

在使用面向?qū)ο蟮恼Z言時，基于消息（事件）的類型過濾是一種比較常見的過濾方式。

為了發(fā)布/訂閱系統(tǒng)的挑戰(zhàn)，MQTT 具有三個服務(wù)質(zhì)量級別，你可以指定消息從客戶端傳到 broker 或者從 broker 傳到客戶端，在 topic 的訂閱中，會存在 topic 沒有 subscriber 訂閱的情況，作為 broker 必須知道如何處理這種情況。

?

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

我們現(xiàn)在知道，MQTT 是一種消息隊列傳輸探測協(xié)議，這種協(xié)議是看似是以消息隊列為基礎(chǔ)，但卻與消息隊列有所差別。

在傳統(tǒng)的消息隊列模式中，一條消息會存儲在消息隊列中等待被消費，每個傳入的消息都存儲在消息隊列中，直到它被客戶端（通常稱之為消費者）所接收，如果沒有客戶端消費消息的話，這條消息就會存在消息隊列中等待被消費。但是在消息隊列中，不會存在消息沒有客戶端消費的情況，但是在?MQTT 中，確存在 topic 無 subscriber 訂閱的情況。

在傳統(tǒng)的消息隊列模式中，一條消息只能被一個客戶端所消費，負載會分布在隊列的每個消費者之間；而在?MQTT 中，每個訂閱者都會受到消息，每個訂閱者有相同的負載。

在傳統(tǒng)的消息隊列模式中，必須使用單獨的命令來顯式創(chuàng)建隊列，只有隊列創(chuàng)建后，才可以生產(chǎn)或者消費消息；而在?MQTT 中，topic 比較靈活，可以即時創(chuàng)建。