隨著 5G 時代的來臨，萬物物聯(lián)的偉大構想正在成為現(xiàn)實。聯(lián)網的物聯(lián)網設備在 2018 年已經達到了 70 億^[1]，在未來兩年，僅智能水電氣表就將超過10億^[2]。

image

海量的設備接入和設備管理對網絡帶寬、通信協(xié)議以及平臺服務架構都帶來了很大挑戰(zhàn)。對于物聯(lián)網協(xié)議來說，必須針對性地解決物聯(lián)網設備通信的幾個關鍵問題：其網絡環(huán)境復雜而不可靠、其內存和閃存容量小、其處理器能力有限。

MQTT 是基于 Publish/Subscribe 模式的物聯(lián)網通信協(xié)議，憑借簡單易實現(xiàn)、支持 QoS、報文小等特點，占據了物聯(lián)網協(xié)議的半壁江山：

image

MQTT 的誕生

MQTT was created by Andy Stanford-Clark of IBM, and Arlen Nipper (then of Arcom Systems, later CTO of Eurotech).^[3]

據 Arlen Nipper 在一 IBM Podcast 上的自述，MQTT 原名是 MQ TT， 注意 MQ 與 TT之間的空格，其全稱為: MQ Telemetry Transport，是九十年代早期，他在參與 Conoco Phillips 公司的一個原油管道數據采集監(jiān)控系統(tǒng)(pipeline SCADA system)時，開發(fā)的一個實時數據傳輸協(xié)議。它的目的在于讓傳感器通過帶寬有限的 VSAT ，與 IBM 的 MQ Integrator 通信。由于 Nipper 是遙感和數據采集監(jiān)控專業(yè)出身，所以按業(yè)內慣例給了個 MQ TT 的名字。

MQTT 設計原則

按照 Nipper 的介紹，MQTT 必須簡單容易實現(xiàn)，必須支持 QoS(設備網絡環(huán)境復雜)，必須輕量且省帶寬(因為那時候帶寬很貴)，必須數據無關(不關心 Payload 數據格式)，必須有持續(xù)地會話感知能力(時刻知道設備是否在線)。下面將介紹 MQTT (3.1.1 版本) 的幾個核心特色，分別對應了這幾個設計原則的實現(xiàn)。

靈活的發(fā)布訂閱和主題設計

發(fā)布訂閱模式是傳統(tǒng) Client/Server 模式的一種解耦方案。發(fā)布者通過 Broker 與消費者之間通信，Broker 的作用是將受到的消息通過某種過濾規(guī)則，正確地發(fā)送給消費者。發(fā)布/訂閱模式 相對于 客戶端/服務器模式 的好處在于：

• 發(fā)布者和消費者之間不必預先知道對方的存在，比如不需要預先溝通對方的 IP Address 和 Port
• 發(fā)布者和消費者之間不必同時運行。因為 Broker 是一直運行的。

在 MQTT 協(xié)議里，上面提到的 過濾規(guī)則 是 Topic。比如：所有發(fā)布到 news 這個 Topic 的消息，都會被 Broker 轉發(fā)給已經訂閱了 news 的訂閱者:

image

上圖中訂閱者預先訂閱了 news，然后發(fā)布者向 Broker 發(fā)布了一條消息 "some msg" 并制定發(fā)布到 news 主題，Broker 通過 Topic 匹配，決定將這條消息轉發(fā)給訂閱者。

MQTT 的 Topic 有層級結構，并且支持通配符 + 和 #:

• + 是匹配單層的通配符。比如 news/+ 可以匹配 news/sports，news/+/basketball 可匹配到 news/sports/basketball。
• # 是一到多層的通配符。比如 news/# 可以匹配 news、 news/sports、news/sports/basketball 以及 news/sports/basketball/x 等等。

MQTT 的主題是不要預先創(chuàng)建的，發(fā)布者發(fā)送消息到某個主題、或者訂閱者訂閱某個主題的時候，Broker 就自動創(chuàng)建了這個主題。

帶寬消耗最小化

MQTT 協(xié)議將協(xié)議本身占用的額外消耗最小化，消息頭部最小只需要占用 2 個字節(jié)。

MQTT 的消息格式分三部分：

MQTT 的主要消息類型有：

• CONNECT / CONNACK
• PUBLISH / PUBACK
• SUBSCRIBE / SUBACK
• UNSUBSCRIBE / UNSUBACK
• PINGREQ / PINGRESP
• DISCONNECT.

其中 PINGREQ / PINGRESP 和 DISCONNECT 報文是不需要可變頭部的，也沒有 Payload，也就是說它們的報文大小僅僅消耗 2 個字節(jié)。

在 CONNECT 報文的可變長度頭部里，有個 Protocol Version 的字段。為了節(jié)省空間，只有一個字節(jié)。所以版本號不是按照字符串 "3.1.1" 存放的，而是使用數字 4 來表示 3.1.1 版本。

三個可選的 QoS 等級

為適應設備不同的網絡環(huán)境，MQTT 設計了 3 個 QoS 等級，0, 1, 2:

• At most once (0)
• At least once (1)
• Exactly once (2).

QoS 0 是一種 "fire and forget" 的消息發(fā)送模式：Sender (可能是 Publisher 或者 Broker) 發(fā)送一條消息之后，就不再關心它有沒有發(fā)送到對方，也不設置任何重發(fā)機制。

QoS 1 包含了簡單的重發(fā)機制，Sender 發(fā)送消息之后等待接收者的 ACK，如果沒收到 ACK 則重新發(fā)送消息。這種模式能保證消息至少能到達一次，但無法保證消息重復。

QoS 2 設計了略微復雜的重發(fā)和重復消息發(fā)現(xiàn)機制，保證消息到達對方并且嚴格值到達一次。

會話保持

MQTT 沒有假設設備或 Broker 使用了 TCP 的保活機制^[3]，而是設計了協(xié)議層的?；顧C制：在 CONNECT 報文里可設置 Keepalive 字段，來設置?；钚奶?PINGREQ/PINGRESP 的發(fā)送時間間隔。當長時間無法收到設備的 PINGREQ 的時候，Broker 就會認為設備已經下線。

總的來說，Keepalive 有兩個作用：

• 發(fā)現(xiàn)對端死亡或者網絡中斷
• 在長時間無消息交互的情況下，保持連接不被網絡設備斷開

對于那些想要在重新上線后，重新收到離線期間錯過的消息的設備，MQTT 設計了持久化連接：在 CONNECT 報文里可設置 CleanSession 字段為 False，則 Broker 會為終端存儲：

• 設備所有的訂閱
• 還未被設備確認的 QoS1 和 QoS 消息
• 設備離線時錯過的消息

在線狀態(tài)感知

MQTT 設計了遺愿(Last Will) 消息，讓 Broker 在發(fā)現(xiàn)設備異常下線的情況下，幫助設備發(fā)布一條遺愿消息到指定的主題。

實際上在某些 MQTT Broker 的實現(xiàn)里 (比如 EMQX)，設備上線或下線的時候 Broker 會通過某些系統(tǒng)主題發(fā)布設備狀態(tài)更新，更符合實際應用場景。

開源 MQTT Broker 如何選擇

到目前為止，比較流行的 MQTT Broker 有幾個：

1. Eclipse Mosquitto: https://github.com/eclipse/mosquitto

   使用 C 語言實現(xiàn)的 MQTT Broker。Eclipse 組織還還包含了大量的 MQTT 客戶端項目：https://www.eclipse.org/paho/#

2. EMQX: https://github.com/emqx/emqx

   使用 Erlang 語言開發(fā)的 MQTT Broker，支持許多其他 IoT 協(xié)議比如 CoAP、LwM2M 等

3. Mosca: https://github.com/mcollina/mosca

   使用 Node.JS 開發(fā)的 MQTT Broker，簡單易用。

4. VerneMQ: https://github.com/vernemq/vernemq

   同樣使用 Erlang 開發(fā)的 MQTT Broker

從支持 MQTT5.0、穩(wěn)定性、擴展性、集群能力等方面考慮，EMQX 的表現(xiàn)應該是最好的：

• 使用 Erlang OTP 開發(fā)，容錯能力好 (電信領域久經考驗的語言，曾經做出過 99.9999999% 可用性的交換機設備^[4])
• 官方有大量的擴展插件可供擴展。有很多認證插件，數據存儲(backend)插件可供選擇?？芍С指鞣N關系型數據庫，NoSQL 數據庫，以及常見消息隊列如 Kafka，RabbitMQ，Pulsar 等
• 支持集群，支持節(jié)點水平擴展
• 單節(jié)點支持 2000K 并發(fā)連接
• 支持規(guī)則引擎和編解碼

作者：EMQ
鏈接：http://m.itdecent.cn/p/32f81eb15d29