1. 為什么工業(yè)物聯(lián)網(wǎng)場(chǎng)景下MQTT成了默認(rèn)選項(xiàng)如果你在工業(yè)現(xiàn)場(chǎng)待過(guò)一定見過(guò)這樣的場(chǎng)景車間里幾十臺(tái)PLC、傳感器、掃碼槍各自跑著不同的協(xié)議Modbus RTU走串口西門子設(shè)備走S7協(xié)議電表走DL/T645想把這些數(shù)據(jù)統(tǒng)一收上來(lái)做集中監(jiān)控光是協(xié)議轉(zhuǎn)換就能把人折騰到崩潰。我最早接觸MQTT是在一個(gè)遠(yuǎn)程抄表項(xiàng)目里當(dāng)時(shí)用輪詢方式采集200多個(gè)點(diǎn)位網(wǎng)絡(luò)稍微抖動(dòng)就丟數(shù)據(jù)后來(lái)?yè)Q成MQTT的發(fā)布訂閱模型設(shè)備主動(dòng)上報(bào)服務(wù)端只管訂閱整個(gè)鏈路一下子清爽了。MQTT全稱Message Queuing Telemetry Transport直譯過(guò)來(lái)叫消息隊(duì)列遙測(cè)傳輸。名字里帶“消息隊(duì)列”容易讓人誤以為它是個(gè)消息中間件其實(shí)它是一套輕量級(jí)的通信協(xié)議規(guī)范跑在TCP/IP之上專門為低帶寬、不穩(wěn)定網(wǎng)絡(luò)環(huán)境下的設(shè)備通信設(shè)計(jì)。工業(yè)物聯(lián)網(wǎng)里設(shè)備數(shù)量多、網(wǎng)絡(luò)環(huán)境復(fù)雜、單臺(tái)設(shè)備算力和電量都有限這三點(diǎn)決定了通信協(xié)議必須滿足幾個(gè)硬指標(biāo)報(bào)文頭足夠小、連接開銷足夠低、支持?jǐn)嗑€重連、能適應(yīng)高延遲網(wǎng)絡(luò)。MQTT恰好把這幾點(diǎn)都做到了。它的核心模型是發(fā)布訂閱加主題路由。設(shè)備不直接跟設(shè)備說(shuō)話而是把消息發(fā)到一個(gè)叫Broker的中間節(jié)點(diǎn)Broker根據(jù)主題把消息分發(fā)給所有訂閱了該主題的客戶端。這個(gè)設(shè)計(jì)帶來(lái)的好處是解耦發(fā)布者不需要知道誰(shuí)在聽訂閱者不需要知道誰(shuí)在發(fā)雙方只認(rèn)主題。工業(yè)場(chǎng)景里設(shè)備增減是常態(tài)今天加一臺(tái)溫濕度傳感器明天撤掉一臺(tái)舊電表用發(fā)布訂閱模型服務(wù)端代碼幾乎不用動(dòng)只要約定好主題規(guī)范就行。這套協(xié)議最早由IBM的Andy Stanford-Clark和Arcom的Arlen Nipper在1999年設(shè)計(jì)當(dāng)時(shí)是為了監(jiān)控石油管道通過(guò)衛(wèi)星鏈路傳輸數(shù)據(jù)。衛(wèi)星鏈路帶寬貴、延遲高所以協(xié)議必須極致精簡(jiǎn)。后來(lái)這套設(shè)計(jì)被OASIS標(biāo)準(zhǔn)化2014年發(fā)布MQTT 3.1.12019年發(fā)布MQTT 5.0?，F(xiàn)在工業(yè)物聯(lián)網(wǎng)平臺(tái)、車聯(lián)網(wǎng)、智能家居、電力監(jiān)控幾乎都能看到MQTT的身影。你如果正在做設(shè)備上云、遠(yuǎn)程監(jiān)控、數(shù)據(jù)采集這類項(xiàng)目MQTT基本是繞不開的一環(huán)。這一章我打算把MQTT的協(xié)議原理和架構(gòu)機(jī)制從頭到尾拆一遍不堆術(shù)語(yǔ)盡量用工業(yè)現(xiàn)場(chǎng)的案例來(lái)解釋每個(gè)設(shè)計(jì)背后的意圖。讀完你應(yīng)該能搞清楚MQTT的報(bào)文長(zhǎng)什么樣、連接是怎么建立的、QoS等級(jí)怎么選、主題怎么設(shè)計(jì)、Broker內(nèi)部大致怎么運(yùn)轉(zhuǎn)以及在實(shí)際部署時(shí)哪些坑最容易踩。2. MQTT協(xié)議整體架構(gòu)與核心概念拆解2.1 發(fā)布訂閱模型到底解決了什么問(wèn)題傳統(tǒng)請(qǐng)求響應(yīng)模型里客戶端要拿數(shù)據(jù)必須主動(dòng)去問(wèn)服務(wù)端這叫輪詢。工業(yè)現(xiàn)場(chǎng)用輪詢有個(gè)致命問(wèn)題設(shè)備數(shù)量一多輪詢周期就拉長(zhǎng)實(shí)時(shí)性直線下降。假設(shè)你有500臺(tái)設(shè)備每臺(tái)輪詢一次耗時(shí)200毫秒輪完一圈就是100秒等數(shù)據(jù)到手早就過(guò)時(shí)了。而且大部分輪詢返回的是“沒(méi)變化”白白浪費(fèi)帶寬和電。發(fā)布訂閱模型把主動(dòng)方換成了設(shè)備。設(shè)備有數(shù)據(jù)就發(fā)沒(méi)數(shù)據(jù)就安靜待著。Broker負(fù)責(zé)把消息推給所有關(guān)心的人。這個(gè)轉(zhuǎn)變帶來(lái)的直接收益是實(shí)時(shí)性由設(shè)備上報(bào)頻率決定不受設(shè)備總數(shù)影響帶寬消耗跟數(shù)據(jù)變化頻率成正比而不是跟設(shè)備數(shù)量成正比服務(wù)端不需要維護(hù)輪詢調(diào)度器架構(gòu)簡(jiǎn)單很多。我做過(guò)一個(gè)對(duì)比測(cè)試同樣采集300個(gè)點(diǎn)位輪詢方案平均延遲8秒MQTT方案平均延遲不到500毫秒而且網(wǎng)絡(luò)流量只有輪詢方案的六分之一。這個(gè)差距在工業(yè)場(chǎng)景里是決定性的因?yàn)楹芏嗫刂七壿嬕竺爰?jí)甚至亞秒級(jí)響應(yīng)。2.2 客戶端、Broker、主題三者的關(guān)系MQTT網(wǎng)絡(luò)里只有兩種角色客戶端和Broker。客戶端可以是發(fā)布者、訂閱者或者兩者都是。Broker是中心節(jié)點(diǎn)所有消息都經(jīng)過(guò)它轉(zhuǎn)發(fā)。這個(gè)中心化設(shè)計(jì)有人會(huì)擔(dān)心單點(diǎn)故障但實(shí)際工業(yè)部署中Broker通常做集群而且MQTT協(xié)議本身對(duì)Broker集群是透明的客戶端不需要知道背后有幾個(gè)Broker。主題是消息的路由地址用斜杠分隔的字符串表示比如factory/line1/temperature。主題不需要預(yù)先創(chuàng)建發(fā)布者往某個(gè)主題發(fā)消息訂閱者訂閱這個(gè)主題就能收到。主題支持通配符匹配單層#匹配多層。比如訂閱factory//temperature能收到factory/line1/temperature和factory/line2/temperature但收不到factory/line1/device1/temperature。訂閱factory/#則能收到factory下所有層級(jí)的消息。這里有個(gè)容易混淆的點(diǎn)主題是大小寫敏感的Factory/Line1和factory/line1是兩個(gè)完全不同的主題。工業(yè)項(xiàng)目里建議統(tǒng)一用小寫加下劃線或斜杠避免因?yàn)榇笮憜?wèn)題導(dǎo)致消息收不到。我見過(guò)一個(gè)項(xiàng)目前端訂閱寫的是Device/Status設(shè)備發(fā)布用的是device/status排查了半天才發(fā)現(xiàn)是大小寫不一致。2.3 報(bào)文結(jié)構(gòu)為什么MQTT能做得這么小MQTT報(bào)文由固定頭、可變頭、有效載荷三部分組成。固定頭最少2字節(jié)第一個(gè)字節(jié)高4位是報(bào)文類型低4位是標(biāo)志位第二個(gè)字節(jié)開始是剩余長(zhǎng)度用變長(zhǎng)編碼表示最多4字節(jié)。可變頭和有效載荷根據(jù)報(bào)文類型不同而不同。固定頭只有2字節(jié)是什么概念對(duì)比HTTP一個(gè)最簡(jiǎn)單的GET請(qǐng)求請(qǐng)求行加請(qǐng)求頭輕松超過(guò)200字節(jié)。MQTT的CONNECT報(bào)文在沒(méi)有任何可選字段時(shí)也就十幾個(gè)字節(jié)。這個(gè)差距在NB-IoT、LoRa這類按流量計(jì)費(fèi)的場(chǎng)景里直接關(guān)系到成本。我算過(guò)一筆賬一個(gè)設(shè)備每分鐘上報(bào)一次數(shù)據(jù)用MQTT一年流量大概幾十兆用HTTP可能要幾百兆差了一個(gè)數(shù)量級(jí)。報(bào)文類型一共14種常用的就那么幾種CONNECT連接、CONNACK連接確認(rèn)、PUBLISH發(fā)布消息、PUBACK發(fā)布確認(rèn)、SUBSCRIBE訂閱、SUBACK訂閱確認(rèn)、PINGREQ心跳請(qǐng)求、PINGRESP心跳響應(yīng)、DISCONNECT斷開連接。記住這幾種日常開發(fā)基本夠用了。2.4 會(huì)話狀態(tài)與Clean Session的取舍MQTT客戶端連接Broker時(shí)可以指定Clean Session標(biāo)志。設(shè)為true表示這次連接不保留任何歷史狀態(tài)斷開后訂閱關(guān)系和未確認(rèn)消息全部丟棄。設(shè)為false表示Broker要保留會(huì)話狀態(tài)包括訂閱關(guān)系和QoS 1、QoS 2的未確認(rèn)消息客戶端重新連接后能繼續(xù)收到離線期間的消息。工業(yè)場(chǎng)景里這個(gè)選擇很關(guān)鍵。比如一個(gè)遠(yuǎn)程泵站網(wǎng)絡(luò)時(shí)斷時(shí)續(xù)如果Clean Session設(shè)為true每次斷線重連后都要重新訂閱而且斷線期間的數(shù)據(jù)全丟了。設(shè)為false的話Broker會(huì)幫它緩存QoS 1以上的消息重連后自動(dòng)補(bǔ)發(fā)。但代價(jià)是Broker要維護(hù)每個(gè)客戶端的會(huì)話狀態(tài)內(nèi)存和存儲(chǔ)開銷會(huì)上去。我的經(jīng)驗(yàn)是對(duì)于數(shù)據(jù)采集類設(shè)備Clean Session設(shè)為falseQoS用1保證數(shù)據(jù)不丟對(duì)于控制指令類設(shè)備Clean Session設(shè)為true因?yàn)榭刂浦噶钣袝r(shí)效性補(bǔ)發(fā)歷史指令反而可能造成誤動(dòng)作。這個(gè)取舍要根據(jù)業(yè)務(wù)場(chǎng)景來(lái)定沒(méi)有一刀切的標(biāo)準(zhǔn)。3. 連接建立與心跳機(jī)制從TCP到MQTT的完整鏈路3.1 CONNECT報(bào)文里都帶了什么客戶端要跟Broker通信第一步是建立TCP連接然后發(fā)送CONNECT報(bào)文。CONNECT報(bào)文里包含幾個(gè)關(guān)鍵字段協(xié)議名和協(xié)議級(jí)別、連接標(biāo)志、保持連接時(shí)間、客戶端ID、用戶名、密碼、遺囑消息。協(xié)議級(jí)別現(xiàn)在常用的是4對(duì)應(yīng)MQTT 3.1.15對(duì)應(yīng)MQTT 5.0。如果客戶端和Broker支持的協(xié)議級(jí)別不一致Broker會(huì)返回CONNACK并拒絕連接。我遇到過(guò)用3.1.1客戶端連5.0 Broker的情況大部分Broker是向下兼容的但有些嚴(yán)格模式會(huì)直接拒絕所以部署前要確認(rèn)版本匹配?？蛻舳薎D是客戶端的唯一標(biāo)識(shí)Broker用它來(lái)識(shí)別會(huì)話。如果兩個(gè)客戶端用同一個(gè)ID連接后連接的會(huì)把先連接的踢掉。工業(yè)項(xiàng)目里客戶端ID建議用設(shè)備序列號(hào)或MAC地址保證唯一性。我見過(guò)有人用隨機(jī)數(shù)做客戶端ID結(jié)果設(shè)備重啟后會(huì)話狀態(tài)全丟了因?yàn)锽roker認(rèn)為這是個(gè)新客戶端。保持連接時(shí)間是個(gè)以秒為單位的整數(shù)客戶端承諾在這個(gè)時(shí)間內(nèi)至少發(fā)一次報(bào)文。如果Broker在這個(gè)時(shí)間的1.5倍內(nèi)沒(méi)收到任何報(bào)文就認(rèn)為客戶端離線觸發(fā)遺囑消息。這個(gè)值設(shè)太小會(huì)導(dǎo)致頻繁心跳設(shè)太大會(huì)導(dǎo)致離線檢測(cè)遲鈍。一般設(shè)30到60秒比較合適網(wǎng)絡(luò)差的場(chǎng)景可以設(shè)到120秒。3.2 遺囑消息設(shè)備掉線后的最后一道保險(xiǎn)遺囑消息是客戶端在CONNECT時(shí)預(yù)先告訴Broker的如果我異常斷線了你幫我把這條消息發(fā)到某個(gè)主題。這個(gè)機(jī)制在工業(yè)監(jiān)控里非常有用。比如一個(gè)溫度傳感器正常時(shí)每分鐘上報(bào)一次數(shù)據(jù)同時(shí)設(shè)置遺囑消息為factory/line1/sensor1/status主題的offline。如果傳感器突然斷電或網(wǎng)絡(luò)中斷Broker檢測(cè)到心跳超時(shí)后會(huì)自動(dòng)發(fā)布這條遺囑消息監(jiān)控端立刻就能知道設(shè)備離線了。遺囑消息的觸發(fā)條件是異常斷線包括TCP連接斷開、心跳超時(shí)、客戶端被踢。如果客戶端主動(dòng)發(fā)送DISCONNECT報(bào)文正常斷開遺囑消息不會(huì)觸發(fā)。這個(gè)區(qū)別很重要因?yàn)檎＞S護(hù)重啟不應(yīng)該觸發(fā)離線告警。遺囑消息的QoS和保留標(biāo)志可以單獨(dú)設(shè)置。建議遺囑消息用QoS 1加保留標(biāo)志確保監(jiān)控端一定能收到而且新訂閱的客戶端也能立刻知道設(shè)備當(dāng)前狀態(tài)。3.3 心跳與Keep Alive的實(shí)際調(diào)優(yōu)心跳機(jī)制靠PINGREQ和PINGRESP兩個(gè)報(bào)文維持?？蛻舳嗽诒３诌B接時(shí)間內(nèi)沒(méi)有其他報(bào)文要發(fā)時(shí)就發(fā)一個(gè)PINGREQBroker回一個(gè)PINGRESP。這個(gè)過(guò)程對(duì)應(yīng)用層是透明的大多數(shù)MQTT客戶端庫(kù)會(huì)自動(dòng)處理。調(diào)優(yōu)心跳間隔要考慮幾個(gè)因素網(wǎng)絡(luò)延遲、設(shè)備功耗、Broker負(fù)載。網(wǎng)絡(luò)延遲大的場(chǎng)景心跳間隔要設(shè)大一點(diǎn)否則PINGREQ還沒(méi)到Broker客戶端就以為超時(shí)了。電池供電的設(shè)備心跳間隔要設(shè)大一點(diǎn)減少喚醒次數(shù)。Broker負(fù)載高的場(chǎng)景心跳間隔也不能太小否則大量PINGREQ會(huì)擠占正常消息的處理資源。我一般這樣估算如果網(wǎng)絡(luò)往返延遲是RTT心跳間隔至少設(shè)為RTT的10倍以上。比如4G網(wǎng)絡(luò)RTT大概100毫秒心跳間隔設(shè)30秒就很安全。如果RTT超過(guò)1秒心跳間隔建議設(shè)到60秒以上。注意有些MQTT客戶端庫(kù)把保持連接時(shí)間設(shè)為0表示禁用心跳這時(shí)候Broker不會(huì)檢測(cè)客戶端離線遺囑消息也不會(huì)觸發(fā)。除非你明確知道自己在做什么否則不要禁用心跳。3.4 連接重試與退避策略工業(yè)現(xiàn)場(chǎng)網(wǎng)絡(luò)不穩(wěn)定是常態(tài)客戶端斷線重連的邏輯必須健壯。最簡(jiǎn)單的做法是斷線后立即重連但這樣在網(wǎng)絡(luò)故障時(shí)會(huì)瘋狂重試把Broker打掛。正確的做法是指數(shù)退避第一次重試等1秒第二次等2秒第三次等4秒一直退到最大間隔比如60秒然后保持這個(gè)間隔重試。有些MQTT客戶端庫(kù)內(nèi)置了退避邏輯有些沒(méi)有需要自己實(shí)現(xiàn)。我建議不管庫(kù)有沒(méi)有內(nèi)置都在應(yīng)用層加一層退避控制因?yàn)閹?kù)的默認(rèn)策略不一定適合你的場(chǎng)景。比如有些庫(kù)默認(rèn)無(wú)限重試且間隔固定在Broker維護(hù)期間會(huì)產(chǎn)生大量無(wú)效連接。重連成功后要檢查會(huì)話狀態(tài)。如果Clean Session為falseBroker會(huì)恢復(fù)之前的訂閱關(guān)系客戶端不需要重新訂閱。但有些Broker實(shí)現(xiàn)有bug重連后訂閱關(guān)系丟失所以保險(xiǎn)起見可以在重連回調(diào)里重新訂閱一次。重復(fù)訂閱同一個(gè)主題不會(huì)報(bào)錯(cuò)Broker會(huì)覆蓋之前的訂閱。4. QoS等級(jí)與消息可靠性工業(yè)場(chǎng)景怎么選4.1 QoS 0最多一次什么時(shí)候能用QoS 0是最簡(jiǎn)單的等級(jí)發(fā)布者發(fā)完就忘Broker收到就轉(zhuǎn)發(fā)不保證消息一定到達(dá)訂閱者。這個(gè)等級(jí)適合什么場(chǎng)景數(shù)據(jù)高頻上報(bào)且允許偶爾丟失的場(chǎng)景。比如環(huán)境溫濕度監(jiān)測(cè)每秒上報(bào)一次丟一兩個(gè)點(diǎn)對(duì)整體趨勢(shì)沒(méi)影響用QoS 0最省資源。QoS 0的報(bào)文里沒(méi)有報(bào)文標(biāo)識(shí)符PUBLISH發(fā)出去就結(jié)束了不需要PUBACK。這意味著發(fā)布者和Broker之間沒(méi)有確認(rèn)機(jī)制Broker和訂閱者之間也沒(méi)有。消息可能在任何一個(gè)環(huán)節(jié)丟失。但它的好處是延遲最低、開銷最小在帶寬緊張的場(chǎng)景下是唯一選擇。我做過(guò)測(cè)試同樣硬件條件下QoS 0的吞吐量大概是QoS 1的3倍延遲只有QoS 1的一半。所以如果業(yè)務(wù)允許丟數(shù)據(jù)QoS 0是性價(jià)比最高的選擇。4.2 QoS 1至少一次重復(fù)消息怎么處理QoS 1保證消息至少到達(dá)一次但可能重復(fù)。發(fā)布者發(fā)PUBLISH后等Broker回PUBACK如果超時(shí)沒(méi)收到就重發(fā)。Broker轉(zhuǎn)發(fā)給訂閱者后等訂閱者回PUBACK超時(shí)也重發(fā)。這個(gè)機(jī)制保證了消息不丟但代價(jià)是可能重復(fù)。重復(fù)消息在工業(yè)場(chǎng)景里可能造成問(wèn)題。比如一個(gè)控制指令“開閥”重復(fù)執(zhí)行兩次可能沒(méi)問(wèn)題但如果是“累加計(jì)數(shù)”這種指令重復(fù)執(zhí)行就會(huì)出錯(cuò)。處理重復(fù)消息有兩種思路一是讓指令冪等執(zhí)行多次和執(zhí)行一次效果一樣二是在應(yīng)用層做去重用消息ID或時(shí)間戳判斷是否已處理。MQTT 5.0之前QoS 1的報(bào)文標(biāo)識(shí)符只有16位范圍1到65535用完后要等確認(rèn)才能復(fù)用。高吞吐場(chǎng)景下這個(gè)范圍可能不夠用導(dǎo)致發(fā)布阻塞。MQTT 5.0引入了主題別名和流控機(jī)制來(lái)緩解這個(gè)問(wèn)題但根本解決辦法還是控制發(fā)布速率。4.3 QoS 2恰好一次代價(jià)有多大QoS 2保證消息恰好到達(dá)一次不丟也不重。實(shí)現(xiàn)方式是四次握手發(fā)布者發(fā)PUBLISHBroker回PUBREC發(fā)布者發(fā)PUBRELBroker回PUBCOMP。Broker到訂閱者之間也是類似的流程。這個(gè)機(jī)制最可靠但開銷也最大延遲最高。QoS 2在工業(yè)場(chǎng)景里用得不多因?yàn)榇蟛糠謭?chǎng)景要么允許丟數(shù)據(jù)用QoS 0要么能容忍重復(fù)用QoS 1加去重。真正需要恰好一次的場(chǎng)景比如計(jì)費(fèi)、交易通常會(huì)在應(yīng)用層再做一層事務(wù)保證不會(huì)只依賴MQTT的QoS 2。我個(gè)人的建議是除非業(yè)務(wù)明確要求恰好一次且無(wú)法在應(yīng)用層去重否則優(yōu)先用QoS 1。QoS 2的額外開銷在設(shè)備數(shù)量多的時(shí)候會(huì)顯著增加Broker負(fù)擔(dān)而且很多Broker對(duì)QoS 2的支持并不完美高并發(fā)下可能出現(xiàn)性能瓶頸。4.4 保留消息與遺囑消息的QoS搭配保留消息是Broker為每個(gè)主題保存的最后一條消息新訂閱該主題的客戶端會(huì)立刻收到這條消息。這個(gè)機(jī)制適合發(fā)布設(shè)備狀態(tài)、配置參數(shù)這類需要“當(dāng)前值”的場(chǎng)景。比如設(shè)備上線后發(fā)布一條保留消息到device/status主題內(nèi)容為online監(jiān)控端任何時(shí)候訂閱都能立刻知道設(shè)備在線。保留消息的QoS建議用1確保Broker一定能存下來(lái)。遺囑消息的QoS也建議用1確保離線告警不丟。但要注意保留消息會(huì)一直存在Broker上如果設(shè)備頻繁發(fā)布保留消息Broker的存儲(chǔ)會(huì)持續(xù)增長(zhǎng)。有些Broker支持保留消息過(guò)期時(shí)間MQTT 5.0也引入了消息過(guò)期間隔部署時(shí)要配置合理的過(guò)期策略。提示保留消息和遺囑消息可以結(jié)合使用。設(shè)備上線時(shí)發(fā)布保留消息online同時(shí)設(shè)置遺囑消息offline。這樣監(jiān)控端訂閱后立刻知道設(shè)備當(dāng)前狀態(tài)設(shè)備掉線后也能收到離線通知。5. 主題設(shè)計(jì)與Broker內(nèi)部機(jī)制5.1 主題命名規(guī)范從混亂到有序主題設(shè)計(jì)是MQTT項(xiàng)目里最容易被忽視但影響最深遠(yuǎn)的部分。我見過(guò)太多項(xiàng)目主題命名隨心所欲data1、test、abc滿天飛后期維護(hù)時(shí)根本不知道哪個(gè)主題對(duì)應(yīng)哪個(gè)設(shè)備。好的主題設(shè)計(jì)應(yīng)該像文件目錄一樣有層次從大到小逐級(jí)細(xì)化。推薦的結(jié)構(gòu)是{企業(yè)}/{廠區(qū)}/{產(chǎn)線}/{設(shè)備類型}/{設(shè)備ID}/{數(shù)據(jù)類別}。比如acme/plant1/line2/sensor/temp001/value。這個(gè)結(jié)構(gòu)的好處是訂閱靈活訂閱整個(gè)廠區(qū)用acme/plant1/#訂閱所有溫度傳感器用acme/plant1//sensor//value訂閱特定設(shè)備用acme/plant1/line2/sensor/temp001/#。主題層級(jí)不宜過(guò)深一般不超過(guò)7層。層級(jí)太深會(huì)導(dǎo)致通配符匹配效率下降而且主題字符串本身也會(huì)占用帶寬。主題名稱也不宜過(guò)長(zhǎng)建議每層控制在20個(gè)字符以內(nèi)。5.2 通配符的匹配規(guī)則與性能影響和#是MQTT主題通配符但它們的匹配規(guī)則有細(xì)微差別。必須獨(dú)占一層factory//temperature是合法的factory/line/temperature是非法的。#必須放在最后factory/#是合法的factory/#/temperature是非法的。從Broker實(shí)現(xiàn)角度看通配符訂閱比精確訂閱開銷大。Broker需要維護(hù)訂閱樹精確訂閱直接定位到節(jié)點(diǎn)通配符訂閱需要遍歷子樹。如果大量客戶端使用#訂閱所有主題Broker的匹配性能會(huì)顯著下降。所以生產(chǎn)環(huán)境要控制通配符訂閱的數(shù)量尤其是#這種全匹配。我一般建議設(shè)備端發(fā)布用精確主題服務(wù)端訂閱可以用通配符但要限制層級(jí)。比如用factory/plant1/#而不是#。如果確實(shí)需要全量訂閱考慮用共享訂閱或者多個(gè)精確訂閱代替。5.3 Broker的會(huì)話管理與消息隊(duì)列Broker內(nèi)部為每個(gè)客戶端維護(hù)一個(gè)會(huì)話對(duì)象包含訂閱列表、未確認(rèn)消息隊(duì)列、QoS 2的狀態(tài)機(jī)等。Clean Session為false時(shí)會(huì)話在客戶端斷開后仍然保留直到會(huì)話過(guò)期或被顯式清除。MQTT 5.0引入了會(huì)話過(guò)期間隔可以設(shè)置會(huì)話保留多長(zhǎng)時(shí)間。未確認(rèn)消息隊(duì)列是Broker內(nèi)存的主要消耗者。QoS 1和QoS 2的消息在收到確認(rèn)前都要留在隊(duì)列里。如果訂閱者處理慢或者網(wǎng)絡(luò)差隊(duì)列會(huì)持續(xù)增長(zhǎng)。Broker通常有隊(duì)列長(zhǎng)度限制超過(guò)限制后要么丟棄舊消息要么拒絕新消息。工業(yè)場(chǎng)景里要根據(jù)設(shè)備數(shù)量和消息頻率估算隊(duì)列大小避免Broker內(nèi)存溢出。我遇到過(guò)一個(gè)案例一個(gè)訂閱者因?yàn)槌绦騜ug卡住不消費(fèi)消息Broker的未確認(rèn)隊(duì)列漲到幾百萬(wàn)條最后OOM崩潰。后來(lái)加了隊(duì)列長(zhǎng)度限制和監(jiān)控告警問(wèn)題才解決。所以Broker的隊(duì)列配置和監(jiān)控是生產(chǎn)環(huán)境必須做的。5.4 共享訂閱與負(fù)載均衡標(biāo)準(zhǔn)MQTT里一條消息會(huì)發(fā)給所有訂閱了該主題的客戶端。但有些場(chǎng)景需要多個(gè)消費(fèi)者分擔(dān)消息比如后端有多個(gè)處理進(jìn)程希望每條消息只被一個(gè)進(jìn)程處理。共享訂閱就是解決這個(gè)問(wèn)題的語(yǔ)法是$share/{group}/{topic}同一個(gè)group下的多個(gè)訂閱者輪流收到消息。共享訂閱在工業(yè)物聯(lián)網(wǎng)里很有用。比如數(shù)據(jù)入庫(kù)服務(wù)部署了多個(gè)實(shí)例用共享訂閱可以自動(dòng)做負(fù)載均衡不需要額外的消息隊(duì)列。但要注意共享訂閱不是MQTT標(biāo)準(zhǔn)的一部分不同Broker的實(shí)現(xiàn)可能不同部署前要確認(rèn)Broker支持。6. 工業(yè)現(xiàn)場(chǎng)部署的常見問(wèn)題與排查實(shí)錄6.1 連接頻繁斷開從網(wǎng)絡(luò)到配置逐層排查設(shè)備頻繁斷線是工業(yè)現(xiàn)場(chǎng)最常見的問(wèn)題。排查思路是從底層往上走先看TCP連接是否穩(wěn)定用ping和traceroute檢查網(wǎng)絡(luò)質(zhì)量再看MQTT心跳是否正常抓包看PINGREQ和PINGRESP的往返時(shí)間最后看Broker日志確認(rèn)斷開原因。常見原因有幾個(gè)心跳間隔設(shè)得太小網(wǎng)絡(luò)稍微抖動(dòng)就超時(shí)客戶端ID沖突兩個(gè)設(shè)備用了同一個(gè)ID互相踢Broker的保持連接時(shí)間配置和客戶端不一致Broker認(rèn)為客戶端超時(shí)了但客戶端還在正常發(fā)心跳網(wǎng)絡(luò)中間有NAT設(shè)備空閑連接被回收。我遇到過(guò)一個(gè)典型案例設(shè)備用4G網(wǎng)絡(luò)心跳間隔設(shè)了15秒但4G網(wǎng)絡(luò)的RTT偶爾會(huì)超過(guò)15秒導(dǎo)致Broker誤判離線。后來(lái)把心跳間隔調(diào)到60秒問(wèn)題就消失了。所以心跳間隔一定要留足余量不能貼著網(wǎng)絡(luò)延遲設(shè)。6.2 消息丟失QoS、保留消息、會(huì)話狀態(tài)的聯(lián)合排查消息丟失可能發(fā)生在多個(gè)環(huán)節(jié)發(fā)布者到Broker、Broker內(nèi)部、Broker到訂閱者。排查時(shí)要先確認(rèn)QoS等級(jí)QoS 0本身就不保證到達(dá)丟消息是正常的。如果用了QoS 1還丟就要檢查會(huì)話狀態(tài)和未確認(rèn)隊(duì)列。一個(gè)常見坑是Clean Session設(shè)為true訂閱者斷線重連后訂閱關(guān)系丟失Broker不知道要給它發(fā)消息。另一個(gè)坑是保留消息被覆蓋如果發(fā)布者頻繁發(fā)布保留消息新訂閱者可能收到的是最新一條而不是它想要的那條。還有一種情況是主題不匹配。發(fā)布者發(fā)到factory/line1/temp訂閱者訂閱的是factory/line1/temperature差一個(gè)字母就收不到。建議在開發(fā)階段用Broker的日志或監(jiān)控工具確認(rèn)消息的實(shí)際流向。6.3 Broker性能瓶頸連接數(shù)、吞吐量、內(nèi)存的監(jiān)控要點(diǎn)Broker的性能瓶頸通常出現(xiàn)在三個(gè)地方連接數(shù)、消息吞吐量、內(nèi)存占用。連接數(shù)受限于文件描述符和內(nèi)存每個(gè)連接大概消耗幾KB到幾十KB內(nèi)存。吞吐量受限于CPU和網(wǎng)絡(luò)帶寬TLS加密會(huì)顯著增加CPU開銷。內(nèi)存占用主要看未確認(rèn)隊(duì)列和保留消息的數(shù)量。監(jiān)控Broker要關(guān)注幾個(gè)指標(biāo)當(dāng)前連接數(shù)、消息入站出站速率、未確認(rèn)消息隊(duì)列長(zhǎng)度、CPU和內(nèi)存使用率、GC頻率Java系Broker。這些指標(biāo)可以用Broker自帶的監(jiān)控接口或Prometheus exporter采集。我一般會(huì)設(shè)置幾個(gè)告警閾值連接數(shù)超過(guò)最大值的80%、未確認(rèn)隊(duì)列超過(guò)10000條、CPU持續(xù)超過(guò)70%、內(nèi)存持續(xù)超過(guò)80%。這些閾值不是絕對(duì)的要根據(jù)實(shí)際硬件和業(yè)務(wù)量調(diào)整。6.4 安全配置認(rèn)證、授權(quán)與傳輸加密工業(yè)物聯(lián)網(wǎng)的安全不能忽視。MQTT支持用戶名密碼認(rèn)證但明文傳輸不安全建議配合TLS使用。TLS會(huì)增加一些開銷但現(xiàn)在的硬件跑TLS基本沒(méi)問(wèn)題除非是極低功耗的MCU。授權(quán)方面Broker通常支持ACL訪問(wèn)控制列表可以限制哪些客戶端能發(fā)布或訂閱哪些主題。比如只允許設(shè)備發(fā)布自己的數(shù)據(jù)主題不允許訂閱其他設(shè)備的主題。這個(gè)配置能有效防止設(shè)備被攻破后的橫向擴(kuò)散。還有一個(gè)容易忽視的點(diǎn)是客戶端證書。用雙向TLS認(rèn)證可以確保只有持有合法證書的設(shè)備才能連接比用戶名密碼更安全。但證書管理是個(gè)麻煩事設(shè)備數(shù)量多的時(shí)候需要一套證書簽發(fā)和吊銷的流程。6.5 常見問(wèn)題速查表問(wèn)題現(xiàn)象可能原因排查方法解決方案設(shè)備頻繁斷線心跳間隔太小抓包看PING往返時(shí)間增大心跳間隔留足余量消息收不到主題不匹配對(duì)比發(fā)布和訂閱主題統(tǒng)一主題命名規(guī)范消息重復(fù)QoS 1重傳檢查PUBACK是否丟失應(yīng)用層去重或改用QoS 2Broker內(nèi)存暴漲未確認(rèn)隊(duì)列積壓查看隊(duì)列長(zhǎng)度監(jiān)控限制隊(duì)列長(zhǎng)度優(yōu)化消費(fèi)者連接被拒絕客戶端ID沖突查看Broker日志確保客戶端ID唯一遺囑消息不觸發(fā)正常斷開檢查是否發(fā)送DISCONNECT異常斷開才會(huì)觸發(fā)遺囑保留消息不更新發(fā)布時(shí)未設(shè)保留標(biāo)志檢查PUBLISH報(bào)文標(biāo)志位發(fā)布時(shí)設(shè)置retain為trueTLS握手失敗證書過(guò)期或不匹配查看TLS握手日志更新證書檢查域名匹配提示這張表建議打印出來(lái)貼在工位上現(xiàn)場(chǎng)排查時(shí)能省不少時(shí)間。很多問(wèn)題其實(shí)都是配置問(wèn)題不是協(xié)議本身的問(wèn)題。7. 從協(xié)議到落地我的幾點(diǎn)實(shí)操體會(huì)MQTT協(xié)議本身不復(fù)雜報(bào)文類型少、交互流程清晰花半天時(shí)間把規(guī)范讀一遍就能理解個(gè)大概。但真正在工業(yè)現(xiàn)場(chǎng)落地難點(diǎn)不在協(xié)議本身而在細(xì)節(jié)配置和異常處理。我做了這么多年踩過(guò)的坑基本都集中在幾個(gè)地方心跳間隔設(shè)得太激進(jìn)、主題命名太隨意、QoS等級(jí)選錯(cuò)、會(huì)話狀態(tài)沒(méi)管好、Broker監(jiān)控缺失。我的建議是項(xiàng)目初期就把主題規(guī)范定下來(lái)寫成文檔所有設(shè)備和服務(wù)端都按這個(gè)規(guī)范來(lái)心跳間隔根據(jù)網(wǎng)絡(luò)質(zhì)量設(shè)寧可大一點(diǎn)也不要貼著極限QoS等級(jí)按業(yè)務(wù)需求選不要無(wú)腦用QoS 2Broker一定要做監(jiān)控連接數(shù)、隊(duì)列長(zhǎng)度、CPU內(nèi)存這些指標(biāo)要能實(shí)時(shí)看到客戶端重連邏輯要加退避避免網(wǎng)絡(luò)故障時(shí)把Broker打掛。還有一點(diǎn)很重要測(cè)試環(huán)境要模擬真實(shí)網(wǎng)絡(luò)條件。很多問(wèn)題在局域網(wǎng)測(cè)試時(shí)發(fā)現(xiàn)不了一到現(xiàn)場(chǎng)就暴露?？梢杂镁W(wǎng)絡(luò)模擬工具制造延遲、丟包、抖動(dòng)提前驗(yàn)證客戶端的健壯性。我一般會(huì)在測(cè)試環(huán)境把丟包率設(shè)到5%、延遲設(shè)到500毫秒能扛過(guò)這個(gè)條件的客戶端到現(xiàn)場(chǎng)基本不會(huì)出大問(wèn)題。MQTT 5.0帶來(lái)了不少新特性比如共享訂閱、主題別名、消息過(guò)期、請(qǐng)求響應(yīng)模式這些在工業(yè)場(chǎng)景里都很有用。但5.0的普及還需要時(shí)間很多設(shè)備和平臺(tái)還在用3.1.1。我的建議是新項(xiàng)目可以直接上5.0老項(xiàng)目升級(jí)要評(píng)估兼容性不要為了新特性強(qiáng)行升級(jí)。最后分享一個(gè)小技巧調(diào)試MQTT時(shí)用mosquitto_sub和mosquitto_pub這兩個(gè)命令行工具非常方便。訂閱所有主題用mosquitto_sub -t # -v發(fā)布消息用mosquitto_pub -t test -m hello。配合-d參數(shù)可以看到詳細(xì)的報(bào)文交互日志排查連接和QoS問(wèn)題特別有用。這兩個(gè)工具在Windows、Linux、macOS上都能跑裝起來(lái)也簡(jiǎn)單建議每個(gè)做MQTT的人都備一份。