一、MQTT 協(xié)議概念

 

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

 

在了解了 MQTT 的概念和應(yīng)用場(chǎng)景后，我們下來就來走進(jìn) MQTT 的學(xué)習(xí)中了，先來看一下 MQTT 有哪些概念。

 

二、MQTT 基礎(chǔ)

 

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

 

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

 

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

 

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

 

2、這個(gè)協(xié)議中的數(shù)據(jù)必須易于傳輸，消耗成本小；

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

1、空間解耦

 

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

 

2、時(shí)間解藕

 

publisher 與 subscriber 并不一定需要同時(shí)運(yùn)行。

 

3、同步 Synchronization 解藕

 

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

 

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

 

四、可拓展性

 

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

 

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

 

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

 

五、消息過濾

 

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

 

1、基于主題的過濾

 

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

 

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

 

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

 

3、基于類型的過濾

 

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

 

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

 

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

 

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

 

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

 

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

 

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