1.先來了解下：
看完得出關鍵字：發布、訂閱模式，事件驅動，主題，生產與消費解耦
2.輕量級
普通的socket連接對服務器的消耗太大了，socket服務端是很消耗資源的，一台服務器能鏈接的客戶端是有限的， 所以才會出現像MQTT這種輕量級低消耗的協議來維護長連接.
除了Socket重量級外，重點是socket數據的生產與消費沒有解耦，如果設備是服務端，上位機必須是客戶端，MQTT它的絕對是比你寫代碼實現的socket穩定好用，
很多人寫出來的socket代碼都經受不住考驗,網上一堆垃圾代碼，（所有也產生了一優秀開源的socket框架 supersocket ，Fastsocket,但它們並不適用於物聯網，為什么不適用又是另一個話題了）
MQTT,目前來說是比較好的一種方式，可以很方便的實現，設備與設備之間，設備與應用程序的消息通訊與解耦。
3.MQTT【只是一個協議】，基於這種協議，實現了服務端中央代碼（如國內的EMQ，國外也有這種軟件），客戶端鏈接的各種API
協議的規范就是TCP的報文內容，說白了就是定義了一串字符串，發送什么內容，就做什么事件（大概意思）。MQTT協議還是要去了解下的，才方便理解內部是怎么運作的。
MQtt【協議】中文文檔
https://mcxiaoke.gitbooks.io/mqtt-cn/content/mqtt/0309-SUBACK.html
4.MQTT是發布訂閱模式，所有的消息都丟到MQTT代理來中轉，根據主題來匹配你來接收的內容，這樣就能實現數據的單向、雙向傳輸
5.一對多的消息通訊傳遞
6.多對一的消息傳遞
7.雙向通訊
8.我的使用場景，數據采集當數量有幾百台以上時，采集到的數據，直接懟到數據庫中時，對數據庫的性能還是有影響的
（有人說服務器能接受幾百個鏈接啊~~），鏈接是能鏈接幾百個，但如果高並發的條件下，對采集的表進行高並發操作的話（同時采集，同時懟相關的幾個表），是很容易造成死鎖或者等待的。
WEB端再去拿這些數據來展現做報表時，性能直線下降，頁面滾動等候好久。
解決辦法可以用MQTT當做Socket服務端來用，把采集到的數據全部丟上MQTT服務器，再寫一個客戶端程序去消費這些消息，消費MQTT代理服務器上的消息就是按消息隊列的方式來消費的，先進先出
用這個方式后，工控機采集的CPU使用率下降一半，web端頁面陳顯也順暢很多，后續這個瞬時數據可優化成，直接從MQTT中讀取，性能會更快。
9.一些設備的瞬間數據，包括web,手機端，上位機，可以直接從MQTT代理服務器上讀取，不走數據庫。性能肯定是最好的
10.安全問題，數據消費端並不需要去了解設備的IP，端口之類的，它只跟MQTT代理服務器聯系。
11.總結：不種的場景，使用不用的技術，MQTT的細節比較多，不一 一陳述了，碼字不易，給個贊唄~~