物聯(lián)網（Internet of Things弟孟，IoT）最近曝光率越來越高。雖然HTTP是網頁的事實標準，不過機器之間（Machine-to-Machine，M2M）的大規(guī)模溝通需要不同的模式：之前的請求/回答（Request/Response）模式不再合適差购，取而代之的是發(fā)布/訂閱（Publish/Subscribe）模式。這就是輕量級汉嗽、可擴展的MQTT（Message Queuing Telemetry Transport）可以施展拳腳的舞臺欲逃。
MQTT簡介
MQTT是基于二進制消息的發(fā)布/訂閱編程模式的消息協(xié)議，最早由IBM提出的饼暑，如今已經成為OASIS規(guī)范稳析。由于規(guī)范很簡單洗做，非常適合需要低功耗和網絡帶寬有限的IoT場景，比如：
- 遙感數據
- 汽車
- 智能家居
- 智慧城市
- 醫(yī)療醫(yī)護
由于物聯(lián)網的環(huán)境是非常特別的彰居，所以MQTT遵循以下設計原則：
- 精簡竭望，不添加可有可無的功能。
- 發(fā)布/訂閱（Pub/Sub）模式裕菠，方便消息在傳感器之間傳遞咬清。
- 允許用戶動態(tài)創(chuàng)建主題，零運維成本奴潘。
- 把傳輸量降到最低以提高傳輸效率旧烧。
- 把低帶寬、高延遲画髓、不穩(wěn)定的網絡等因素考慮在內掘剪。
- 支持連續(xù)的會話控制。
- 理解客戶端計算能力可能很低奈虾。
- 提供服務質量管理夺谁。
- 假設數據不可知，不強求傳輸數據的類型與格式肉微，保持靈活性匾鸥。
運用MQTT協(xié)議，設備可以很方便地連接到物聯(lián)網云服務碉纳，管理設備并處理數據勿负，最后應用到各種業(yè)務場景，如下圖所示：
發(fā)布/訂閱模式
與請求/回答這種同步模式不同劳曹，發(fā)布/訂閱模式解耦了發(fā)布消息的客戶（發(fā)布者）與訂閱消息的客戶（訂閱者）之間的關系奴愉，這意味著發(fā)布者和訂閱者之間并不需要直接建立聯(lián)系。打個比方铁孵，你打電話給朋友锭硼，一直要等到朋友接電話了才能夠開始交流，是一個典型的同步請求/回答的場景蜕劝；而給一個好友郵件列表發(fā)電子郵件就不一樣檀头，你發(fā)好電子郵件該干嘛干嘛，好友們到有空了去查看郵件就是了熙宇，是一個典型的異步發(fā)布/訂閱的場景鳖擒。
熟悉編程的同學一定非常熟悉這種設計模式了溉浙，因為它帶來了這些好處：
- 發(fā)布者與訂閱者不必了解彼此烫止，只要認識同一個消息代理即可。
- 發(fā)布者和訂閱者不需要交互戳稽，發(fā)布者無需等待訂閱者確認而導致鎖定馆蠕。
- 發(fā)布者和訂閱者不需要同時在線期升，可以自由選擇時間來消費消息。
主題
MQTT是通過主題對消息進行分類的互躬，本質上就是一個UTF-8的字符串播赁，不過可以通過反斜杠表示多個層級關系。主題并不需要創(chuàng)建吼渡，直接使用就是了容为。
主題還可以通過通配符進行過濾。其中寺酪，+可以過濾一個層級坎背，而#只能出現在主題最后表示過濾任意級別的層級。
舉個例子：
- building-b/floor-5：代表B樓5層的設備寄雀。
- +/floor-5：代表任何一個樓的5層的設備得滤。
- building-b/#：代表B樓所有的設備。
注意：MQTT允許使用通配符訂閱主題盒犹，但是并不允許使用通配符廣播懂更。
服務質量
為了滿足不同的場景，MQTT支持三種不同級別的服務質量（Quality of Service急膀，QoS）為不同場景提供消息可靠性：
- 級別0：盡力而為沮协。消息發(fā)送者會想盡辦法發(fā)送消息，但是遇到意外并不會重試卓嫂。
- 級別1：至少一次皂股。消息接收者如果沒有知會或者知會本身丟失，消息發(fā)送者會再次發(fā)送以保證消息接收者至少會收到一次命黔，當然可能造成重復消息呜呐。
- 級別2：恰好一次。保證這種語義肯定會減少并發(fā)或者增加延時悍募，不過丟失或者重復消息是不可接受的時候蘑辑，級別2是最合適的。
服務質量是個老話題了坠宴。級別2所提供的不重不丟很多情況下是最理想的洋魂，不過往返多次的確認一定對并發(fā)和延遲帶來影響。級別1提供的至少一次語義在日志處理這種場景下是完全OK的喜鼓，所以像Kafka這類的系統(tǒng)利用這一特點減少確認從而大大提高了并發(fā)副砍。級別0適合雞肋數據場景，食之無味棄之可惜庄岖，就這么著吧豁翎。
消息類型
MQTT擁有14種不同的消息類型：
- CONNECT：客戶端連接到MQTT代理
- CONNACK：連接確認
- PUBLISH：新發(fā)布消息
- PUBACK：新發(fā)布消息確認，是QoS 1給PUBLISH消息的回復
- PUBREC：QoS 2消息流的第一部分隅忿，表示消息發(fā)布已記錄
- PUBREL：QoS 2消息流的第二部分心剥，表示消息發(fā)布已釋放
- PUBCOMP：QoS 2消息流的第三部分邦尊，表示消息發(fā)布完成
- SUBSCRIBE：客戶端訂閱某個主題
- SUBACK：對于SUBSCRIBE消息的確認
- UNSUBSCRIBE：客戶端終止訂閱的消息
- UNSUBACK：對于UNSUBSCRIBE消息的確認
- PINGREQ：心跳
- PINGRESP：確認心跳
- DISCONNECT：客戶端終止連接前優(yōu)雅地通知MQTT代理
后面我們會給出具體的例子。
MQTT代理
市面上有相當多的高質量MQTT代理优烧，其中mosquitto是一個開源的輕量級的C實現蝉揍，完全兼容了MQTT 3.1和MQTT 3.1.1。下面我們就以mosquitto為例演示一下MQTT的使用畦娄。環(huán)境是百度開放云的云服務器以及Ubuntu 14.04.1 LTS又沾，簡單起見MQTT代理和客戶端都安裝在同一臺云服務器上了。
首先SSH到云服務器熙卡，安裝mosquitto以及搭配的客戶端：
sudo apt-get install mosquitto
sudo apt-get install mosquitto-clients
現在在云端模擬云服務捍掺，訂閱某辦公樓5層的溫度作為主題：
mosquitto_sub -d -t 'floor-5/temperature'
Received CONNACK
Received SUBACK
Subscribed (mid: 1): 0
然后另外打開一個SSH連接，模擬溫度計發(fā)送溫度消息：
mosquitto_pub -d -t 'floor-5/temperature' -m '15'
Received CONNACK
Sending PUBLISH (d0, q0, r0, m1, 'floor-5/temperature', ... (2 bytes))
此時回到第一個SSH客戶端可以看到信息已經接收到了再膳，之后便是心跳消息：
Received PUBLISH (d0, q0, r0, m0, 'floor-5/temperature', ... (2 bytes))
15
Sending PINGREQ
Received PINGRESP
需要注意的是mosquitto客戶端默認使用QoS 0挺勿，下面我們使用QoS 2訂閱這個主題：
mosquitto_sub -d -q 2 -t 'floor-5/temperature'
Received CONNACK
Received SUBACK
Subscribed (mid: 1): 2
切換到另外SSH連接然后在這個主題里面發(fā)送溫度消息：
mosquitto_pub -d -q 2 -t 'floor-5/temperature' -m '15'
Received CONNACK
Sending PUBLISH (d0, q2, r0, m1, 'floor-5/temperature', ... (2 bytes))
Received PUBREC (Mid: 1)
Sending PUBREL (Mid: 1)
Received PUBCOMP (Mid: 1)
此時回到第一個SSH客戶端可以看到信息已經接收到了，以及相應的多次握手消息：
Received PUBLISH (d0, q2, r0, m1, 'floor-5/temperature', ... (2 bytes))
Sending PUBREC (Mid: 1)
Received PUBREL (Mid: 1)
15
Sending PUBCOMP (Mid: 1)
至此我們初步了解了MQTT的基本知識喂柒，祝大家在物聯(lián)網的世界里面玩得開心不瓶！
