數據採集，SCADA, 使用MQTT的方式來進行消息單/雙向傳輸,什麼場景使用MQTT

 

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的細節比較多，不一 一陳述了，碼字不易，給個讚唄~~