1. 從一次“收不到消息”的排查說(shuō)起做物聯(lián)網(wǎng)或者嵌入式開(kāi)發(fā)的朋友應(yīng)該對(duì)MQTT不陌生。我最早接觸MQTT是在一個(gè)智能家居網(wǎng)關(guān)項(xiàng)目里當(dāng)時(shí)設(shè)備端和云端之間要頻繁上報(bào)狀態(tài)、下發(fā)指令調(diào)研了一圈發(fā)現(xiàn)MQTT協(xié)議輕量、省電、帶寬占用小非常適合這種場(chǎng)景。但真正上手之后才意識(shí)到這協(xié)議有個(gè)很大的“認(rèn)知門檻”它和你以前用過(guò)的HTTP、TCP直連這類“點(diǎn)對(duì)點(diǎn)”通信完全不是一個(gè)玩法。HTTP是你問(wèn)一句我答一句MQTT則是發(fā)布、訂閱、轉(zhuǎn)發(fā)這套很多人第一次接觸時(shí)腦子里還是“客戶端發(fā)給服務(wù)器服務(wù)器處理”的傳統(tǒng)模型結(jié)果就很容易陷入那種“我明明把消息發(fā)出來(lái)了Broker也收到了為什么對(duì)端就是收不到”的困境里。這篇文章想跟你好好聊聊MQTT最核心的三個(gè)概念發(fā)布/訂閱模式、Broker服務(wù)的職責(zé)、Topic主題機(jī)制。我會(huì)結(jié)合我自己實(shí)際項(xiàng)目中踩過(guò)的坑比如Topic設(shè)計(jì)不合理導(dǎo)致的消息串?dāng)_、QoS等級(jí)選錯(cuò)導(dǎo)致的重復(fù)或丟失、還有那些讓人頭疼的“不訂閱就想收到消息”的誤解把原理用大白話講清楚再給你一套能直接用的實(shí)操建議。無(wú)論你是剛開(kāi)始接觸物聯(lián)網(wǎng)協(xié)議的新手還是已經(jīng)被MQTT折磨過(guò)幾次的老手這篇文章應(yīng)該都能幫到你。2. 發(fā)布/訂閱模式為什么它和“一問(wèn)一答”完全不同2.1 快遞柜模型一條消息從哪來(lái)、到哪去要理解MQTT的發(fā)布/訂閱模式我建議你放下“服務(wù)器-客戶端”的傳統(tǒng)思路想象一個(gè)快遞柜。快遞柜里有很多格子每個(gè)格子上貼了一個(gè)標(biāo)簽。投遞員發(fā)布者把包裹放進(jìn)某個(gè)格子里貼上標(biāo)簽然后走人。取件人訂閱者如果想要某個(gè)標(biāo)簽的包裹就去對(duì)應(yīng)的格子里取。整個(gè)過(guò)程中投遞員完全不知道取件人長(zhǎng)什么樣、在哪里、什么時(shí)候來(lái)取件人也完全不知道投遞員是誰(shuí)、什么時(shí)候來(lái)投遞。他們之間唯一的聯(lián)系就是那個(gè)“格子標(biāo)簽”。這里有個(gè)關(guān)鍵點(diǎn)快遞柜本身也就是Broker只負(fù)責(zé)暫存和轉(zhuǎn)發(fā)它不關(guān)心包裹里的內(nèi)容也不關(guān)心是誰(shuí)投遞的、誰(shuí)要取走。只要格子標(biāo)簽對(duì)得上就完成了使命。MQTT就是這套邏輯在網(wǎng)絡(luò)世界的實(shí)現(xiàn)。發(fā)布者Publisher把消息發(fā)給Broker時(shí)不需要指定“我要發(fā)給哪個(gè)客戶端”只需要指定這個(gè)消息歸屬的Topic主題比如home/bedroom/temperature。Broker收到這條消息后會(huì)根據(jù)這個(gè)Topic把它轉(zhuǎn)發(fā)給所有“訂閱”了這個(gè)Topic的客戶端Subscriber。多對(duì)多、松散耦合這就是發(fā)布/訂閱模式最核心的價(jià)值。2.2 跟傳統(tǒng)請(qǐng)求/響應(yīng)模式的本質(zhì)區(qū)別傳統(tǒng)HTTP模型是典型的“請(qǐng)求-響應(yīng)”模式客戶端主動(dòng)請(qǐng)求服務(wù)器被動(dòng)響應(yīng)客戶端要時(shí)刻知道服務(wù)器的地址、端口、路徑服務(wù)器也要知道是哪個(gè)客戶端在通信。這種模式在“多對(duì)一”的場(chǎng)景下沒(méi)問(wèn)題但放到物聯(lián)網(wǎng)里就不太夠用了。想象一下你有一萬(wàn)個(gè)設(shè)備如果每個(gè)設(shè)備都直接向服務(wù)器發(fā)起連接并一直保持服務(wù)器壓力能大到崩潰如果設(shè)備只是想“被動(dòng)接收”一條指令可它又不能時(shí)刻掛著一個(gè)HTTP長(zhǎng)連接輪詢效率就太低了。發(fā)布/訂閱模式解決的就是這種“誰(shuí)來(lái)主動(dòng)通信”的痛。發(fā)布方不用管接收方是誰(shuí)訂閱方也不用管發(fā)布方是誰(shuí)雙方只要跟同一個(gè)Broker打交道并把Topic約定好就能完成通信。設(shè)備端只需要維護(hù)一條到Broker的長(zhǎng)連接既不用頻繁輪詢,消息也能“主動(dòng)”推送到設(shè)備端。這個(gè)模型在降低耦合、提高擴(kuò)展性和容錯(cuò)性上的優(yōu)勢(shì)是傳統(tǒng)直連模式很難替代的。2.3 “不訂閱就能收到消息”關(guān)于消息路由的真相很多剛接觸MQTT的朋友都會(huì)問(wèn)一個(gè)經(jīng)典問(wèn)題“Broker里有個(gè)Topic我不訂閱能不能直接去取這個(gè)Topic的消息”還有熱詞里那句話“mqtt broker可以接收到發(fā)布的主題的內(nèi)容嗎不需要訂閱”。這其實(shí)是一個(gè)典型的對(duì)“郵箱”和“聊天群”概念的混淆。答案是MQTT里不訂閱就收不到任何消息。Broker不會(huì)為某個(gè)客戶端留存“所有Topic的歷史消息”讓你按需拉取除非你使用retained message保留消息或者啟用了持久會(huì)話加隊(duì)列但即便是這兩種情況前提也是你曾經(jīng)訂閱過(guò)只是消息會(huì)在你離線時(shí)被暫存等你重新上線再補(bǔ)發(fā)。Topic本身不是一個(gè)“數(shù)據(jù)表”不是存了一條就一定在那兒等你來(lái)讀。它更像一個(gè)“廣播頻段”只有調(diào)到了這個(gè)頻段的人才能聽(tīng)到內(nèi)容。如果抱著“不訂閱也能拿數(shù)據(jù)”的想法去做對(duì)接大概率會(huì)踩坑。我見(jiàn)過(guò)有人拿Kepserver做MQTT網(wǎng)關(guān)對(duì)接時(shí)配置了一堆Topic結(jié)果點(diǎn)位掃描不到折騰很久才發(fā)現(xiàn)是訂閱列表和發(fā)布列表根本沒(méi)對(duì)齊Broker壓根沒(méi)把數(shù)據(jù)路由給他。這一點(diǎn)在后面的實(shí)操章節(jié)我會(huì)展開(kāi)講。3. Broker服務(wù)不只是“中轉(zhuǎn)站”還是“郵局”和“路由器”3.1 Broker的三大職責(zé)接收、過(guò)濾、分發(fā)Broker是MQTT體系里的核心節(jié)點(diǎn)所有消息都經(jīng)過(guò)它。它的職責(zé)可以濃縮成三個(gè)詞接收、過(guò)濾、分發(fā)。接收接受發(fā)布者發(fā)來(lái)的消息處理客戶端的連接、鑒權(quán)、心跳等基礎(chǔ)動(dòng)作。過(guò)濾根據(jù)消息的Topic篩選出哪些訂閱者對(duì)這個(gè)Topic感興趣這一步通常在內(nèi)部通過(guò)“訂閱關(guān)系表”來(lái)完成。分發(fā)把消息推送給所有匹配的訂閱者。這里的“匹配”不僅包括完整匹配還涉及到Topic通配符的模糊匹配比較復(fù)雜后面會(huì)專門講。你可以把Broker想象成一個(gè)帶路由功能的郵局。信件消息送到郵局后郵局不看內(nèi)容只看信封上的地址Topic然后決定把它投送到哪些收件人訂閱者的信箱里。這個(gè)比喻能解釋一個(gè)關(guān)鍵點(diǎn)Broker對(duì)消息內(nèi)容是完全無(wú)感的。它不解析數(shù)據(jù)格式不管是JSON、二進(jìn)制還是CSV它都一視同仁地轉(zhuǎn)發(fā)。所以通信雙方的報(bào)文結(jié)構(gòu)、字段含義必須自己在應(yīng)用層約定好。這是很多團(tuán)隊(duì)對(duì)接時(shí)容易忽略的地方以為“MQTT協(xié)議統(tǒng)一了數(shù)據(jù)格式也統(tǒng)一了”其實(shí)協(xié)議只是管道管子里流什么貨是你自己的事。3.2 常見(jiàn)Broker選型Mosquitto、EMQX、NanoMQ各有什么優(yōu)劣市面上的Broker實(shí)現(xiàn)非常多從輕量的單機(jī)級(jí)到支持百萬(wàn)連接的企業(yè)級(jí)都有。我簡(jiǎn)單列幾個(gè)常用的附帶我的實(shí)際使用感受。Broker定位優(yōu)點(diǎn)缺點(diǎn)適用場(chǎng)景Mosquitto輕量單機(jī)部署簡(jiǎn)單、資源占用小、生態(tài)成熟集群能力弱、管理界面少學(xué)習(xí)、測(cè)試、小規(guī)模產(chǎn)線項(xiàng)目EMQX企業(yè)級(jí)分布高并發(fā)、插件豐富、有Dashboard、規(guī)則引擎重、資源要求高、許可證需關(guān)注大規(guī)模物聯(lián)網(wǎng)平臺(tái)、邊緣網(wǎng)關(guān)NanoMQ輕量高性能資源占用極低、吞吐高、支持嵌入式社區(qū)文檔相對(duì)少、功能模塊在完善中嵌入式網(wǎng)關(guān)、資源受限場(chǎng)景HiveMQ企業(yè)級(jí)性能穩(wěn)定、企業(yè)支持好商業(yè)授權(quán)費(fèi)用高對(duì)SLA要求極高的場(chǎng)景如果你是剛開(kāi)始學(xué)MQTT或者設(shè)備量并不大我強(qiáng)烈建議先用Mosquitto把協(xié)議原理摸透了。我至今還記得自己第一次在樹(shù)莓派上敲下mosquitto -v然后用兩個(gè)終端分別訂閱和發(fā)布消息的那一刻那種“通了”的感覺(jué)特別直觀。如果你要做的是生產(chǎn)級(jí)平臺(tái)比如接入幾千上萬(wàn)個(gè)設(shè)備、還要消息持久化、規(guī)則引擎、多租戶隔離那直接上EMQX會(huì)更省心。3.3 Broker里到底存了什么發(fā)布的消息有歷史記錄嗎這是不少人在實(shí)際項(xiàng)目里用錯(cuò)的點(diǎn)。默認(rèn)情況下Broker是不存儲(chǔ)普通消息的。一條消息轉(zhuǎn)發(fā)給當(dāng)前所有匹配的訂閱者之后就徹底從內(nèi)存里消失了。除非你配置了消息持久化插件或者使用了Session隊(duì)列只給離線恢復(fù)用且需要持久會(huì)話和Clean Sessionfalse否則發(fā)布過(guò)的消息沒(méi)有任何歷史記錄可言。這也就意味著你先發(fā)布、后訂閱是收不到之前那條消息的。這在邏輯上完全自洽訂閱就是“實(shí)時(shí)收聽(tīng)”不是“回放錄像”。如果你需要新上線的設(shè)備立刻拿到當(dāng)前設(shè)備狀態(tài)的快照比如最新溫濕度那么正確做法是使用Retained Message保留消息。Broker會(huì)為每個(gè)Topic保存“最后一條”retained消息當(dāng)新的訂閱者上線時(shí)Broker會(huì)立刻把這條保留消息推給新訂閱者。注意每個(gè)Topic只能保留最新的一條。如果你需要完整的歷史數(shù)據(jù)那必須自己搞存儲(chǔ)——把Broker收到的數(shù)據(jù)落庫(kù)或者接時(shí)序數(shù)據(jù)庫(kù)這些都是應(yīng)用層面的設(shè)計(jì)。3.4 心跳、遺囑和會(huì)話這三個(gè)機(jī)制別忽略Broker除了負(fù)責(zé)轉(zhuǎn)發(fā)消息還有三個(gè)“隱形功能”對(duì)你實(shí)際運(yùn)維極其重要。第一是心跳機(jī)制Keep Alive?？蛻舳嗽谶B接時(shí)會(huì)告訴Broker一個(gè)心跳間隔比如60秒。在這60秒內(nèi)如果客戶端沒(méi)有發(fā)送任何報(bào)文包括數(shù)據(jù)消息和PINGREQBroker就認(rèn)為它失聯(lián)了會(huì)主動(dòng)斷開(kāi)連接。這個(gè)機(jī)制保證了Broker不會(huì)為僵尸連接保留一堆無(wú)效會(huì)話。實(shí)際排查問(wèn)題時(shí)如果設(shè)備頻繁掉線又重連心跳設(shè)置得是否合理往往是第一個(gè)要查的點(diǎn)。第二是遺囑消息Last Will and Testament, LWT?？蛻舳嗽谶B接時(shí)可以順便告訴Broker如果檢測(cè)到我意外斷線了請(qǐng)幫我發(fā)一條“我掛了”的消息到某個(gè)Topic。這在設(shè)備狀態(tài)跟蹤中非常有用。比如你的網(wǎng)關(guān)上有10個(gè)節(jié)點(diǎn)某一個(gè)節(jié)點(diǎn)斷電了它的LWT消息會(huì)被Broker投遞到指定Topic平臺(tái)收到后就能及時(shí)標(biāo)記該節(jié)點(diǎn)離線而不是等到超時(shí)才被動(dòng)發(fā)現(xiàn)。第三是持久會(huì)話Clean Session / Persistence。如果客戶端連接時(shí)設(shè)置了Clean SessionfalseBroker會(huì)為它保留訂閱關(guān)系并在它離線期間把發(fā)給它的消息緩存起來(lái)受隊(duì)列長(zhǎng)度限制。等它重新上線時(shí)Broker會(huì)把這些“存起來(lái)”的消息繼續(xù)推給它。這在弱網(wǎng)環(huán)境下很實(shí)用設(shè)備一會(huì)兒斷一會(huì)兒連但重要的指令不會(huì)丟。不過(guò)要注意消息積壓是有限度的積壓太多會(huì)觸發(fā)丟棄策略千萬(wàn)別把它設(shè)計(jì)成無(wú)限緩存。4. Topic主題機(jī)制這里的設(shè)計(jì)比你想的更講究4.1 Topic的層級(jí)結(jié)構(gòu)跟文件路徑挺像但又不完全一樣Topic在MQTT里是一個(gè)UTF-8字符串用來(lái)標(biāo)識(shí)消息的類別。習(xí)慣上會(huì)用類似文件路徑的斜杠/來(lái)分層比如設(shè)備上報(bào)溫度devices/sensor-001/telemetry/temperature平臺(tái)下發(fā)指令devices/sensor-001/commands/reboot平臺(tái)間廣播system/broadcast/upgrade這種層級(jí)結(jié)構(gòu)不是協(xié)議強(qiáng)制的但強(qiáng)烈建議你遵循。它能讓Topic更有可讀性也方便你使用通配符做批量訂閱。一個(gè)容易忽略的技術(shù)點(diǎn)Topic層級(jí)之間是“嚴(yán)格分隔”的斜杠不是普通字符。比如home/bedroom/temperature和home/bedroom/temperature/是兩個(gè)不同的Topic多了一個(gè)空層級(jí)。我之前就踩過(guò)這個(gè)坑設(shè)備端發(fā)布的Topic結(jié)尾帶了個(gè)斜杠平臺(tái)訂閱時(shí)沒(méi)帶結(jié)果點(diǎn)了半天就是收不到消息排查了整整一個(gè)下午。這種“看不見(jiàn)的差異”確實(shí)陰。4.2 通配符的匹配邏輯加號(hào)還是井號(hào)搞混了會(huì)出事MQTT支持兩種通配符單層通配符和多層通配符#。理解它們的最直接方式就是背下來(lái)這兩條規(guī)則匹配一個(gè)層級(jí)且只能占一個(gè)完整層級(jí)#匹配剩余所有層級(jí)而且必須是Topic的最后一個(gè)字符舉例說(shuō)明訂閱home//temperature能收到home/bedroom/temperature、home/kitchen/temperature但收不到home/bedroom/floor/temperature因?yàn)槔锩娑嗔藗€(gè)floor層級(jí)訂閱home/#能收到home/bedroom/light、home/bedroom/ac/status、home/kitchen/status基本就是把home/下所有東西都撈走很多人會(huì)搞混和#的區(qū)別尤其是訂閱home/#后以為能收到所有home相關(guān)的消息結(jié)果發(fā)現(xiàn)當(dāng)發(fā)布者發(fā)布的是device/...而不是home/...開(kāi)頭時(shí)咋收都收不到。這其實(shí)是層級(jí)根路徑就不匹配的問(wèn)題跟通配符本身沒(méi)關(guān)系。還有一個(gè)細(xì)節(jié)#匹配“剩余所有層級(jí)”包括零個(gè)層級(jí)。比如訂閱home/#也能收到發(fā)往home本身的消息。匹配的是單個(gè)層級(jí)不能用來(lái)匹配“空層級(jí)”。提示通配符只能用在訂閱端不能用在發(fā)布端。發(fā)布消息時(shí)必須指定一個(gè)具體的、不含通配符的Topic。這其實(shí)是一種保護(hù)機(jī)制防止一條廣播消息被搞成無(wú)限擴(kuò)散。4.3 Topic設(shè)計(jì)規(guī)范命名、分層與避免混亂的經(jīng)驗(yàn)Topic設(shè)計(jì)是MQTT項(xiàng)目里最容易被輕視、后來(lái)最痛苦的問(wèn)題。命名混亂的Topic后期擴(kuò)功能幾乎寸步難行。我總結(jié)了幾條實(shí)踐經(jīng)驗(yàn)。第一統(tǒng)一前綴按設(shè)備維度分層。比如所有設(shè)備消息統(tǒng)一以devices/開(kāi)頭然后跟設(shè)備ID、數(shù)據(jù)類型、動(dòng)作。這樣既方便按設(shè)備訂閱也方便用通配符做數(shù)據(jù)聚合。第二區(qū)分上行和下行。設(shè)備上報(bào)和平臺(tái)下發(fā)的語(yǔ)義完全不同不建議混在同一個(gè)層級(jí)里?？梢杂胻elemetry遙測(cè)、commands指令、events事件、config配置這樣的動(dòng)作詞把上行和下行分開(kāi)避免業(yè)務(wù)邏輯互相干擾。第三不要讓Topic結(jié)構(gòu)嵌套過(guò)深。一般來(lái)說(shuō)控制在4到6層以內(nèi)是比較舒服的。層級(jí)過(guò)深一方面訂閱表達(dá)式冗長(zhǎng)另一方面通配符匹配的性能也會(huì)下降雖然Broker一般會(huì)做前綴樹(shù)優(yōu)化但可讀性損失更大。第四禁止動(dòng)態(tài)隨機(jī)字符串當(dāng)層級(jí)。比如有人把設(shè)備端的UUID直接拼到Topic里例如devices/7b7a6c4d-xxxx/telemetry/temperature。這么做雖然能區(qū)分設(shè)備但當(dāng)你需要批量訂閱所有設(shè)備的時(shí)候通配符寫起來(lái)會(huì)非常別扭你也無(wú)法通過(guò)Topic一眼看出設(shè)備歸屬。更合理的做法是設(shè)備信息放消息體里Topic保留穩(wěn)定的結(jié)構(gòu)性前綴。示例如下# 推薦風(fēng)格 devices/{device_group}/{device_id}/telemetry/temperature devices/{device_group}/{device_id}/commands/reboot # 不推薦風(fēng)格 device_data/{動(dòng)態(tài)ID序號(hào)}/random_string/temp4.4 刪除Topic你是想刪訂閱還是想讓舊設(shè)備不再發(fā)消息熱詞里有個(gè)“刪除topic”這其實(shí)是一個(gè)高頻誤解。很多人以為Broker里有個(gè)Topic列表可以像刪數(shù)據(jù)庫(kù)表一樣刪掉一個(gè)Topic。實(shí)際上Broker并不持有“Topic列表”這種概念。當(dāng)沒(méi)有任何客戶端訂閱、也沒(méi)有retained消息時(shí)一個(gè)Topic自然就不存在了。所以“刪除Topic”這種操作本質(zhì)上就兩件事讓所有訂閱方取消訂閱Unsubscribe。如果這個(gè)Topic有retained消息把它清除掉發(fā)布一條空消息的retained消息或者用Broker管理API清掉。至于舊設(shè)備繼續(xù)往這個(gè)Topic發(fā)消息那就沒(méi)辦法從Broker側(cè)“屏蔽掉”你得管設(shè)備或者從應(yīng)用層設(shè)計(jì)上讓設(shè)備不再發(fā)布。在這個(gè)問(wèn)題上糾結(jié)是沒(méi)有意義的MQTT的設(shè)計(jì)哲學(xué)就是“無(wú)人看管Topic即不存在”。4.5 $SYS、$share、帶$前綴的主題用的少但別踩坑MQTT協(xié)議約定以$開(kāi)頭的Topic是系統(tǒng)保留Topic普通客戶端不能隨便發(fā)布。常見(jiàn)的包括$SYS/broker/clients/connected、$SYS/broker/load/messages/received等。這些是Broker自己向外界匯報(bào)運(yùn)行狀態(tài)的Topic你可以訂閱來(lái)監(jiān)控Broker健康度。$share前綴則是MQTT共享訂閱的專用前綴用于把相同訂閱分組內(nèi)的消息輪流分發(fā)實(shí)現(xiàn)負(fù)載均衡。它長(zhǎng)這樣$share/group1/devices//telemetry訂閱了同一組名的多個(gè)客戶端會(huì)輪流收到消息這在做橫向擴(kuò)展的消費(fèi)者集群時(shí)非常有用。但注意$share的完整語(yǔ)法是$share/{group}/{filter}它的{group}并不是Topic層級(jí)的一部分只是一個(gè)分組標(biāo)識(shí)。如果沒(méi)搞明白這點(diǎn)很多人會(huì)在配置共享訂閱時(shí)寫成$share/devices/這種形式導(dǎo)致語(yǔ)義完全不對(duì)。對(duì)于一般的小項(xiàng)目$SYS和$share可以暫時(shí)不碰但了解一下沒(méi)壞處。面試的時(shí)候問(wèn)到MQTT如果能把這兩個(gè)前綴講清楚往往是一個(gè)不錯(cuò)的加分項(xiàng)。5. 消息質(zhì)量與可靠性的維度QoS、Retained、Session這一套組合拳5.1 QoS 0/1/2 到底幫我干了什么MQTT最容易被面試官問(wèn)到、也最容易在實(shí)際使用中犯迷糊的就是QoS等級(jí)。它定義了一條消息從發(fā)布者到訂閱者這條鏈路上的投遞保證。注意QoS是端到端的但拆開(kāi)看發(fā)布者到Broker的傳輸和Broker到訂閱者的傳輸各自獨(dú)立遵循自己的QoS等級(jí)。QoS 0至多一次消息發(fā)出去就不管了。不確認(rèn)、不重發(fā)。最快但可能丟。QoS 1至少一次接收方收到后回一個(gè)PUBACK發(fā)送方?jīng)]收到PUBACK就重發(fā)。消息肯定能到但可能重復(fù)。QoS 2只有一次借助四段握手PUBLISH - PUBREC - PUBREL - PUBCOMP保證消息不丟不重。最慢但最可靠。因?yàn)镼oS 1可能導(dǎo)致重復(fù)所以接收方需要自行做去重或者業(yè)務(wù)本身能容忍重復(fù)操作比如狀態(tài)上報(bào)是冪等的。QoS 2雖然可靠但開(kāi)銷高、吞吐低一般不建議大量使用。我自己的經(jīng)驗(yàn)是設(shè)備上報(bào)遙測(cè)用QoS 0或者QoS 1設(shè)備控制指令用QoS 1極少數(shù)對(duì)重復(fù)零容忍的場(chǎng)景比如支付確認(rèn)、文件包傳輸才用QoS 2。5.2 Retained Message的正確用法不是緩存是“最新?tīng)顟B(tài)”Retained Message前面簡(jiǎn)單提過(guò)這里展開(kāi)講透。當(dāng)一條消息發(fā)布時(shí)如果帶上了retain標(biāo)志Broker會(huì)保存這條消息的“新值”并讓后續(xù)任何新訂閱該Topic的客戶端都能立刻收到這份“最新?tīng)顟B(tài)”。這個(gè)機(jī)制特別適合“上線即同步狀態(tài)”的場(chǎng)景。舉個(gè)例子一個(gè)智能燈的狀態(tài)是“亮著的”如果燈斷電重啟它可能丟失自己到內(nèi)存狀態(tài)。那平臺(tái)訂閱lights/room01/status后能立刻從retained消息里拿到“亮著”把狀態(tài)同步回來(lái)。如果不使用retained平臺(tái)只能被動(dòng)等燈上報(bào)狀態(tài)那期間界面可能一直是“未知”體驗(yàn)很差。但要注意retained消息不會(huì)過(guò)期它會(huì)一直放在Broker里直到被新消息覆蓋或手動(dòng)清除。所以如果某個(gè)設(shè)備的生命周期結(jié)束了記得要“清掉”它的retained消息否則新接入的同ID設(shè)備上線時(shí)會(huì)瞬間收到老設(shè)備最后的殘留狀態(tài)產(chǎn)生嚴(yán)重誤導(dǎo)。5.3 Clean Session / Session Expiry離線消息保留多久MQTT 3.1.1 中cleanSession決定會(huì)話是否持久。true表示每次連接都是全新的Broker不保存任何訂閱關(guān)系和離線消息false表示創(chuàng)建持久會(huì)話Broker保存訂閱關(guān)系并在客戶端離線期間緩存QoS 1/2消息QoS 0消息一般不會(huì)緩存即便在持久會(huì)話中也可能被丟棄。MQTT 5.0 把這一概念升級(jí)為Session Expiry Interval把“是否持久”改成“持久多久”更靈活。如果你在做弱網(wǎng)設(shè)備比如車載硬件動(dòng)不動(dòng)進(jìn)隧道就沒(méi)信號(hào)建議用持久會(huì)話加上短一點(diǎn)的過(guò)期時(shí)間既能保證指令下發(fā)達(dá)得到又不會(huì)讓Broker堆積太多無(wú)效會(huì)話。5.4 消息膨脹和背壓高并發(fā)下Broker的生存之道當(dāng)大量設(shè)備同時(shí)上報(bào)時(shí)Broker要處理的不僅僅是轉(zhuǎn)發(fā)還有背壓?jiǎn)栴}。簡(jiǎn)單說(shuō)如果某個(gè)訂閱者處理速度很慢它大概率會(huì)拖慢Broker的投遞效率。比如你有一個(gè)數(shù)據(jù)采集服務(wù)訂閱了一個(gè)包含百萬(wàn)級(jí)消息的Topic但它消費(fèi)速度跟不上那Broker的發(fā)送緩沖區(qū)會(huì)越堆越高最終可能把Broker內(nèi)存壓垮。解決辦法有幾個(gè)方向一是用共享訂閱把同一條消息流量分?jǐn)偟蕉鄠€(gè)消費(fèi)者二是加強(qiáng)客戶端消費(fèi)能力比如批量寫入數(shù)據(jù)庫(kù)三是在協(xié)議層控制QoS能用0的不用1減少重發(fā)壓力四是對(duì)慢消費(fèi)者做消息丟棄策略寧可丟舊的、不堵新的。做生產(chǎn)系統(tǒng)時(shí)一定要對(duì)著壓測(cè)數(shù)據(jù)反復(fù)調(diào)別等到線上宕機(jī)再后悔。6. 實(shí)操環(huán)節(jié)用Mosquitto 命令行把整個(gè)機(jī)制跑通6.1 本地快速搭建Broker環(huán)境紙上談兵終覺(jué)淺。這里我?guī)阍诒镜匕袽QTT跑通一遍用最原生的Mosquitto命令行工具不看任何圖形界面把所有原理親手驗(yàn)證一遍。Windows下直接上官網(wǎng)下載mosquitto安裝包Linux下sudo apt install mosquitto mosquitto-clientsmacOS用brew install mosquitto。裝完以后先啟動(dòng)Brokermosquitto -v-v是verbose模式能看到詳細(xì)的連接、訂閱、發(fā)布日志。這一步至關(guān)重要排查問(wèn)題最省事的辦法就是看Broker日志。然后再開(kāi)三個(gè)終端終端A訂閱一個(gè)Topic終端B發(fā)布消息終端C繼續(xù)觀察Broker日志6.2 三步驗(yàn)證發(fā)布/訂閱、通配符和Retained先來(lái)最基礎(chǔ)的。終端Amosquitto_sub -t devices/sensor01/temperature -v終端Bmosquitto_pub -t devices/sensor01/temperature -m {value:25.5}這時(shí)終端A里會(huì)出現(xiàn)一條帶Topic前綴的JSON數(shù)據(jù)。你注意看Broker的日志輸出它會(huì)清楚地展示一條PUBLISH從設(shè)備端進(jìn)來(lái)、再被路由到訂閱端的過(guò)程。這就是整個(gè)MQTT鏈路最小閉環(huán)。接下來(lái)驗(yàn)證通配符。終端A按CtrlC停掉重新訂閱mosquitto_sub -t devices//temperature -v終端B發(fā)布一條devices/sensor02/temperature的消息你會(huì)發(fā)現(xiàn)終端A同樣收到了。然后把訂閱改成devices/#再發(fā)布devices/sensor01/humidity同樣也能收到。這就是通配符匹配的實(shí)際效果。最后驗(yàn)證retained。先訂閱一個(gè)從未有過(guò)保留消息的Topicdevices/sensor01/config你會(huì)發(fā)現(xiàn)終端A里什么都沒(méi)有。停掉終端A然后用retain標(biāo)志發(fā)布mosquitto_pub -t devices/sensor01/config -m {interval:60} -r再重新訂閱devices/sensor01/config這回終端A會(huì)立刻收到這條{interval:60}盡管它是在消息發(fā)布之后才訂閱的。這就是retained的含義——Broker為你保存了“最新?tīng)顟B(tài)”并主動(dòng)推給新訂閱者。6.3 結(jié)合Kepserver/RSLinx的工業(yè)網(wǎng)關(guān)對(duì)接經(jīng)驗(yàn)熱詞里提到的“rslinx配置了topic,掃描不到點(diǎn)位”和“kepserver mqtt”我在工控集成項(xiàng)目里也折騰過(guò)。簡(jiǎn)單分享下這類網(wǎng)關(guān)對(duì)接的典型排查路徑。KepserverEx和RSLinx這類工業(yè)軟件里的“MQTT Broker”配置往往是讓你填寫B(tài)roker地址、端口、訂閱或發(fā)布的Topic然后把PLC點(diǎn)位映射到Topic或消息Payload里。最常見(jiàn)的“掃描不到點(diǎn)位”問(wèn)題原因通常是這幾類Topic不匹配網(wǎng)關(guān)配置的是訂閱某個(gè)Topic來(lái)獲取指令但平臺(tái)發(fā)布到的是另一個(gè)Topic兩邊根本沒(méi)交集。排查方法就是Broker開(kāi)verbose日志看消息實(shí)際進(jìn)出走向。Payload格式對(duì)不上網(wǎng)關(guān)側(cè)可能期望純標(biāo)簽名或者固定格式平臺(tái)側(cè)發(fā)的是JSON嵌套字段解析不了自然“掃不到”。訂閱關(guān)系和通配符沒(méi)對(duì)齊網(wǎng)關(guān)里寫了points/#可平臺(tái)發(fā)布的是points/alldata如果網(wǎng)關(guān)里寫成了points/就匹配不到。注意看通配符每個(gè)字符。點(diǎn)位名稱大小寫、分隔符不一致比如網(wǎng)關(guān)里點(diǎn)是DB1_REAL0平臺(tái)里寫成了db1.real0這種肉眼很難發(fā)現(xiàn)最好把文本導(dǎo)出比對(duì)一遍。如果早年間你也被這種“明明在線、卻沒(méi)有數(shù)據(jù)”的問(wèn)題困住過(guò)大概率就是上面四種情況之一。我現(xiàn)在的排查順序是先看Broker日志里有沒(méi)有消息流再看Topic樹(shù)能否匹配最后摳Payload格式。這三板斧走完基本都能定位。6.4 用Apache Kafka類比理解Broker但不完全一樣很多做過(guò)大數(shù)據(jù)的人會(huì)拿Kafka和MQTT的Broker做類比但這倆差別非常大。Kafka的Topic是分區(qū)化的持久日志消費(fèi)者通過(guò)offset自行控制讀到哪里消息會(huì)長(zhǎng)期保留按保留策略更偏“數(shù)據(jù)管道”MQTT的Broker更像一個(gè)瞬時(shí)消息交換機(jī)默認(rèn)不保留歷史消息只能被推給“在線的、訂閱匹配的”客戶端消費(fèi)軌跡由Broker管理而不是消費(fèi)者。兩者的“Topic”一詞都有但語(yǔ)義完全不同。如果你非要做跨系統(tǒng)集成很多架構(gòu)是“MQTT Broker收設(shè)備消息再通過(guò)Connector把數(shù)據(jù)灌入Kafka”這樣既保證了設(shè)備側(cè)的輕量也拿到了Kafka強(qiáng)大的流處理能力。這種混搭在實(shí)際項(xiàng)目里很常見(jiàn)。7. 典型問(wèn)題排查與避坑手冊(cè)7.1 高頻問(wèn)題速查表現(xiàn)象可能原因排查動(dòng)作客戶端已連接但收不到消息訂閱的Topic和發(fā)布的不匹配通配符用錯(cuò)retained消息沒(méi)設(shè)用mosquitto_sub -t訂閱#全量觀察查Broker日志消息收到但內(nèi)容是亂碼Payload編碼不一致UTF-8 vs GBK二進(jìn)制串當(dāng)文本顯示檢查發(fā)布端編碼方式統(tǒng)一為UTF-8偶發(fā)重復(fù)消息QoS 1導(dǎo)致重復(fù)投遞消費(fèi)端做冪等處理重發(fā)場(chǎng)景下使用消息ID去重設(shè)備頻繁掉線心跳間隔太短網(wǎng)絡(luò)不穩(wěn)定調(diào)大Keep Alive間隔開(kāi)啟持久會(huì)話上線拿不到最新?tīng)顟B(tài)沒(méi)用retained訂閱先于發(fā)布對(duì)狀態(tài)類Topic使用-r標(biāo)志發(fā)布Broker內(nèi)存持續(xù)增長(zhǎng)訂閱端消費(fèi)太慢持久會(huì)話消息積壓引入共享訂閱增加消費(fèi)者調(diào)小隊(duì)列長(zhǎng)度7.2 一條消息從發(fā)布到訂閱的完整流轉(zhuǎn)細(xì)節(jié)為了幫你徹底搞懂我描述一次“完整旅程”。設(shè)備A發(fā)布一條QoS 1消息到devices/a/data帶retain標(biāo)志。消息先走到BrokerBroker校驗(yàn)該客戶端是否有該Topic的發(fā)布權(quán)限如果開(kāi)啟了ACL然后查看當(dāng)前訂閱關(guān)系表。假設(shè)客戶端B訂閱了devices//data客戶端C訂閱了devices/#那Broker會(huì)把消息同時(shí)投遞給B和C每條投遞鏈路各自遵循B和C訂閱時(shí)要求的QoS。如果B離線但開(kāi)啟了持久會(huì)話消息就會(huì)進(jìn)入B的離線隊(duì)列如果C在線就直接推送。同時(shí)因?yàn)閞etain標(biāo)志存在Broker還會(huì)把消息存到retained消息表里供未來(lái)的新訂閱者使用。如果這條消息是QoS 1Broker還會(huì)在收到設(shè)備A的PUBACK確認(rèn)后才算完成“發(fā)布者到Broker”這段旅程。這個(gè)流程理解透了MQTT的“底褲”你基本就看清了。7.3 一個(gè)容易混淆的案例一個(gè)Topic被多端發(fā)布誰(shuí)說(shuō)了算實(shí)際項(xiàng)目中經(jīng)常出現(xiàn)多個(gè)端往同一個(gè)Topic發(fā)消息的情況比如設(shè)備上報(bào)和平臺(tái)修復(fù)工具都在往devices/x/config里寫。如果兩邊用retained同時(shí)寫就會(huì)互相覆蓋。這種問(wèn)題的本質(zhì)不在協(xié)議而在你定義Topic時(shí)的“所有權(quán)”不清。我建議給每一個(gè)Topic明確規(guī)定“唯一的責(zé)任方”。例如devices/x/config只允許平臺(tái)寫入設(shè)備只有訂閱權(quán)限。設(shè)備上報(bào)狀態(tài)用devices/x/telemetry/state這樣發(fā)布權(quán)限天然分區(qū)誰(shuí)也不干擾誰(shuí)。如果有人非要用同一個(gè)Topic做雙向通信那不是協(xié)議的問(wèn)題而是設(shè)計(jì)的問(wèn)題后面接手的同事大概率會(huì)罵人。7.4 監(jiān)聽(tīng)#時(shí)你能不能看到所有消息這是又一個(gè)高頻面試題用mosquitto_sub -t # -v訂閱所有消息能不能看到Broker上的所有信息答案是能訂閱到所有普通Topic但無(wú)法訂閱到設(shè)備發(fā)往$SYS的消息而且Broker不一定允許你先做發(fā)布端過(guò)濾。$SYS消息是Broker自身的“私人廣播”普通客戶端不允許往$SYS下發(fā)布消息但可以訂閱部分$SYS主題來(lái)監(jiān)控Broker指標(biāo)。如果你真想看到“所有消息”還得小心那些從建立連接到真正訂閱完成之間的“空窗期”消息丟失這些細(xì)節(jié)往往被忽略。8. 一些后續(xù)可以繼續(xù)深挖的方向MQTT這個(gè)協(xié)議看起來(lái)簡(jiǎn)單但用好了它整個(gè)系統(tǒng)的架構(gòu)能變得非常干凈。我在實(shí)際項(xiàng)目里體會(huì)特別深的幾條經(jīng)驗(yàn)簡(jiǎn)單分享給你。第一Topic規(guī)范最好在項(xiàng)目第一天就定下來(lái)。后續(xù)改Topic命名比改數(shù)據(jù)庫(kù)表結(jié)構(gòu)還痛苦因?yàn)闋可娴剿性诰€設(shè)備固件升級(jí)。一定要把設(shè)備分組、設(shè)備ID、數(shù)據(jù)類型、動(dòng)作語(yǔ)義這些維度提前規(guī)劃好寧可前期多想幾天也不要后期返工。第二能不用QoS 2就別用QoS 2。大部分業(yè)務(wù)場(chǎng)景下QoS 1加冪等處理已經(jīng)足夠可靠了。QoS 2的協(xié)議開(kāi)銷和實(shí)現(xiàn)復(fù)雜度往往超出一般團(tuán)隊(duì)的預(yù)期。如果你的場(chǎng)景真的需要“不丟不重”那就要做好完整的四段握手、報(bào)文去重和狀態(tài)管理測(cè)試千萬(wàn)別拍腦袋就上。第三監(jiān)控Broker本身比監(jiān)控設(shè)備更重要。MQTT是星型拓?fù)銪roker一掛全網(wǎng)癱瘓。建議至少把Broker的CPU、內(nèi)存、連接數(shù)、消息吞吐、訂閱數(shù)以及$SYS里那幾個(gè)關(guān)鍵指標(biāo)接入監(jiān)控告警系統(tǒng)。EMQX自帶的Dashboard已經(jīng)做得很好Mosquitto也有大量可訂閱的$SYS指標(biāo)都沒(méi)有理由不接。第四設(shè)備端固件的異常斷線處理永遠(yuǎn)比正常流程重要。MQTT是為弱網(wǎng)設(shè)計(jì)的斷線重連、會(huì)話恢復(fù)、遺囑上報(bào)這些機(jī)制一定要在設(shè)備端做充分測(cè)試。我見(jiàn)過(guò)很多項(xiàng)目業(yè)務(wù)代碼都寫得很順一遇到網(wǎng)線被踢、電池耗盡這種邊緣情況就原形畢露。用LWT做離線感知用持久會(huì)話做指令補(bǔ)償這套組合拳值得你認(rèn)真對(duì)待。最后再分享一個(gè)小技巧如果你用命令行調(diào)試問(wèn)題記得mosquitto_sub -t # -v永遠(yuǎn)是你的第一武器。訂閱全量、觀察實(shí)際消息流向很多玄學(xué)問(wèn)題瞬間就變成了明牌問(wèn)題。這一招在我這些年的排查經(jīng)歷里至少救了我十次。希望這篇關(guān)于MQTT核心原理的梳理也能幫你把底層的幾個(gè)概念徹底捋順。如果不小心在哪個(gè)點(diǎn)卡住了用上面的命令親手試一遍你會(huì)發(fā)現(xiàn)一切其實(shí)很簡(jiǎn)單。