MQTT入門篇

物聯網（Internet of Things，IoT）最近曝光率愈來愈高。雖然HTTP是網頁的事實標準，不過機器之間（Machine-to-Machine，M2M）的大規模溝通須要不一樣的模式：以前的請求/回答（Request/Response）模式再也不合適，取而代之的是發佈/訂閱（Publish/Subscribe）模式。這就是輕量級、可擴展的MQTT（Message Queuing Telemetry Transport）能夠施展拳腳的舞臺。

MQTT簡介

MQTT是基於二進制消息的發佈/訂閱編程模式的消息協議，最先由IBM提出的，現在已經成爲OASIS規範。因爲規範很簡單，很是適合須要低功耗和網絡帶寬有限的IoT場景，好比：

• 遙感數據
• 汽車
• 智能家居
• 智慧城市
• 醫療醫護

因爲物聯網的環境是很是特別的，因此MQTT遵循如下設計原則：

1. 精簡，不添加無關緊要的功能。
2. 發佈/訂閱（Pub/Sub）模式，方便消息在傳感器之間傳遞。
3. 容許用戶動態建立主題，零運維成本。
4. 把傳輸量降到最低以提升傳輸效率。
5. 把低帶寬、高延遲、不穩定的網絡等因素考慮在內。
6. 支持連續的會話控制。
7. 理解客戶端計算能力可能很低。
8. 提供服務質量管理。
9. 假設數據不可知，不強求傳輸數據的類型與格式，保持靈活性。

運用MQTT協議，設備能夠很方便地鏈接到物聯網雲服務，管理設備並處理數據，最後應用到各類業務場景，以下圖所示：

發佈/訂閱模式

與請求/回答這種同步模式不一樣，發佈/訂閱模式解耦了發佈消息的客戶（發佈者）與訂閱消息的客戶（訂閱者）之間的關係，這意味着發佈者和訂閱者之間並不須要直接創建聯繫。打個比方，你打電話給朋友，一直要等到朋友接電話了纔可以開始交流，是一個典型的同步請求/回答的場景；而給一個好友郵件列表發電子郵件就不同，你發好電子郵件該幹嗎幹嗎，好友們到有空了去查看郵件就是了，是一個典型的異步發佈/訂閱的場景。

熟悉編程的同窗必定很是熟悉這種設計模式了，由於它帶來了這些好處：

• 發佈者與訂閱者沒必要了解彼此，只要認識同一個消息代理便可。
• 發佈者和訂閱者不須要交互，發佈者無需等待訂閱者確認而致使鎖定。
• 發佈者和訂閱者不須要同時在線，能夠自由選擇時間來消費消息。

主題

MQTT是經過主題對消息進行分類的，本質上就是一個UTF-8的字符串，不過能夠經過反斜槓表示多個層級關係。主題並不須要建立，直接使用就是了。

主題還能夠經過通配符進行過濾。其中，+能夠過濾一個層級，而#只能出如今主題最後表示過濾任意級別的層級。

舉個例子：

• building-b/floor-5：表明B樓5層的設備。
• +/floor-5：表明任何一個樓的5層的設備。
• building-b/#：表明B樓全部的設備。

注意，MQTT容許使用通配符訂閱主題，可是並不容許使用通配符廣播。

服務質量

爲了知足不一樣的場景，MQTT支持三種不一樣級別的服務質量（Quality of Service，QoS）爲不一樣場景提供消息可靠性：

• 級別0：盡力而爲。消息發送者會想盡辦法發送消息，可是遇到意外並不會重試。
• 級別1：至少一次。消息接收者若是沒有知會或者知會自己丟失，消息發送者會再次發送以保證消息接收者至少會收到一次，固然可能形成重複消息。
• 級別2：剛好一次。保證這種語義確定會減小併發或者增長延時，不過丟失或者重複消息是不可接受的時候，級別2是最合適的。

服務質量是個老話題了。級別2所提供的不重不丟不少狀況下是最理想的，不過往返屢次的確認必定對併發和延遲帶來影響。級別1提供的至少一次語義在日誌處理這種場景下是徹底OK的，因此像Kafka這類的系統利用這一特色減小確認從而大大提升了併發。級別0適合雞肋數據場景，食之無味棄之惋惜，就這麼着吧。

消息類型

MQTT擁有14種不一樣的消息類型：

1. CONNECT：客戶端鏈接到MQTT代理
2. CONNACK：鏈接確認
3. PUBLISH：新發布消息
4. PUBACK：新發布消息確認，是QoS 1給PUBLISH消息的回覆
5. PUBREC：QoS 2消息流的第一部分，表示消息發佈已記錄
6. PUBREL：QoS 2消息流的第二部分，表示消息發佈已釋放
7. PUBCOMP：QoS 2消息流的第三部分，表示消息發佈完成
8. SUBSCRIBE：客戶端訂閱某個主題
9. SUBACK：對於SUBSCRIBE消息的確認
10. UNSUBSCRIBE：客戶端終止訂閱的消息
11. UNSUBACK：對於UNSUBSCRIBE消息的確認
12. PINGREQ：心跳
13. PINGRESP：確認心跳
14. DISCONNECT：客戶端終止鏈接前優雅地通知MQTT代理