1. 從一次實(shí)際故障聊起為什么選錯(cuò) QoS 會(huì)讓人半夜爬起來修先說個(gè)我踩過的坑。某次給一套物聯(lián)網(wǎng)設(shè)備做數(shù)據(jù)采集傳感器每隔幾秒上報(bào)一次溫濕度我圖省事把所有消息都設(shè)成了 QoS 0覺得丟了就丟了下一條馬上就來。結(jié)果客戶現(xiàn)場(chǎng)出現(xiàn)間歇性數(shù)據(jù)空洞運(yùn)維同事查到半夜最后發(fā)現(xiàn)是弱網(wǎng)環(huán)境下報(bào)文頻繁丟失而業(yè)務(wù)側(cè)又拿這條數(shù)據(jù)做告警判斷一個(gè)空洞直接觸發(fā)誤報(bào)。反過來另一個(gè)項(xiàng)目里我把所有下行控制指令都設(shè)成了 QoS 2結(jié)果設(shè)備量上來之后broker 的 Qos 2 報(bào)文處理隊(duì)列積壓嚴(yán)重指令延遲從幾十毫秒飆升到好幾秒。兩次教訓(xùn)讓我徹底明白一件事MQTT 的 QoS 不是越高越好選錯(cuò)才是真麻煩。在選擇 QoS 之前得先弄清楚它到底解決什么問題。MQTT 是應(yīng)用層協(xié)議跑在 TCP 之上按理說 TCP 已經(jīng)保證了字節(jié)流的可靠傳輸為什么還需要業(yè)務(wù)層的 QoS 等級(jí)原因在于 MQTT 的通信模型是客戶端 - broker - 客戶端而 broker 是獨(dú)立進(jìn)程TCP 只保證單條連接上的字節(jié)不丟不亂不保證 broker 在轉(zhuǎn)發(fā)消息、處理 session、管理訂閱關(guān)系時(shí)不出岔子。同時(shí)MQTT 消息是發(fā)布 / 訂閱的異步模式發(fā)布者發(fā)完就完事訂閱者可能在某個(gè)時(shí)間點(diǎn)才上線這中間消息在 broker 里怎么存、怎么保證不重復(fù)不丟失TCP 根本管不著。所以 QoS 實(shí)際上是客戶端與 broker 之間、以及 broker 與訂閱端之間的協(xié)議層可靠性約定從每次握手需要交換多少個(gè)報(bào)文就能看得很清楚。這篇文章我把 QoS 0、1、2 逐個(gè)拆開核心關(guān)注點(diǎn)只有一個(gè)它們各自在投遞一條消息時(shí)到底要交換多少報(bào)文、狀態(tài)機(jī)長什么樣、失敗時(shí)誰來負(fù)責(zé)重試、以及這些機(jī)制在真實(shí)業(yè)務(wù)中對(duì)應(yīng)的代價(jià)是什么。把這幾個(gè)問題算明白你自然知道什么場(chǎng)景用什么等級(jí)。2. QoS 0一發(fā)一收的裸奔模式到底省在哪QoS 0 是整個(gè)協(xié)議里最干脆的等級(jí)官方術(shù)語叫 At most once最多一次投遞。它的行為就是發(fā)送端把 PUBLISH 報(bào)文扔出去然后什么都不管沒有 ACK沒有重傳沒有消息 ID。broker 收到之后往匹配的訂閱者那邊轉(zhuǎn)發(fā)一條 PUBLISH同樣不確認(rèn)。2.1 報(bào)文數(shù)量與協(xié)議行為一條 QoS 0 消息的完整鏈路報(bào)文數(shù)量極其固定發(fā)送端向 broker 發(fā)送 1 個(gè) PUBLISH 報(bào)文broker 向每個(gè)匹配的訂閱端轉(zhuǎn)發(fā) 1 個(gè) PUBLISH 報(bào)文全程 0 個(gè)確認(rèn)報(bào)文如果發(fā)送端和訂閱端有 N 個(gè)匹配訂閱關(guān)系那么一條原始消息最多產(chǎn)生1 N個(gè) PUBLISH 報(bào)文除此之外沒有任何額外的握手開銷。這里有一個(gè)容易忽略的細(xì)節(jié)PUBLISH 報(bào)文的固定頭里QoS 等級(jí)只占 2 bitQoS 0 對(duì)應(yīng)的值是 0所以 DUP 標(biāo)志位、RETAIN 標(biāo)志位的組合也相對(duì)簡(jiǎn)單。沒有 QoS 0 的消息沒有 Packet ID或者說 Packet ID 字段長度為 0這意味著從協(xié)議層面根本無法追蹤某一條消息是否被送達(dá)。2.2 省下來的開銷背后是什么QoS 0 最大的價(jià)值是極低的延遲和極小的帶寬占用。對(duì)于上報(bào)型業(yè)務(wù)比如環(huán)境溫濕度、GPS 坐標(biāo)、設(shè)備心跳這類數(shù)據(jù)天然有時(shí)間價(jià)值衰減一條數(shù)據(jù)過了幾秒就是廢數(shù)據(jù)重傳舊數(shù)據(jù)反而會(huì)干擾下游分析。與其糾結(jié)丟沒丟不如盡快把最新值送過去。而且這類消息量大、頻率高如果每條都走確認(rèn)流程broker 的 CPU 和網(wǎng)絡(luò) IO 都會(huì)明顯上升最終反而擠壓了真正重要的控制消息的帶寬。但省下的代價(jià)也清清楚楚消息可能丟失。TCP 層只保證字節(jié)流到達(dá) broker不保證 broker 應(yīng)用層一定能把消息成功寫入訂閱者的會(huì)話。比如訂閱者正好在斷線重連瞬間消息被 broker 發(fā)往舊的 socketTCP 連接關(guān)閉時(shí)數(shù)據(jù)被丟棄QoS 0 不會(huì)觸發(fā)任何重發(fā)再比如 broker 內(nèi)部路由處理時(shí)發(fā)現(xiàn)沒有匹配的訂閱者消息直接丟棄也不會(huì)告訴發(fā)送端。這些行為在協(xié)議規(guī)范里都是允許的所以業(yè)務(wù)代碼必須把可能丟消息當(dāng)成默認(rèn)前提來設(shè)計(jì)。2.3 一個(gè)容易犯的認(rèn)知錯(cuò)誤很多人以為反正應(yīng)用層自己會(huì)做數(shù)據(jù)校驗(yàn)QoS 0 丟了我可以從別的地方補(bǔ)然后給所有消息都用 QoS 0。這個(gè)思路在純數(shù)據(jù)采集、且下游能做時(shí)序拼接的場(chǎng)景下是合理的但在以下場(chǎng)景就危險(xiǎn)了告警觸發(fā)類消息比如設(shè)備溫度越限、電量低丟了可能就是一次安全事故狀態(tài)變更類消息比如設(shè)備在線 / 離線切換、門鎖開閉丟了會(huì)導(dǎo)致業(yè)務(wù)側(cè)狀態(tài)字段和實(shí)際不符冪等性較弱的下行控制消息比如切換工作模式重發(fā)或丟失都會(huì)造成狀態(tài)漂移所以我現(xiàn)在的習(xí)慣是把所有消息按可丟性分三檔QoS 0 只放丟掉之后對(duì)業(yè)務(wù)無影響或影響可自然恢復(fù)的那一檔。這不是保守而是吃過虧之后的經(jīng)驗(yàn)。3. QoS 1多一來回買到的是至少一次的確定性QoS 1 全稱 At least once至少一次投遞。它的引入提供了消息到達(dá)確認(rèn)機(jī)制但同時(shí)也引入了重復(fù)消息的可能性。這個(gè)等級(jí)應(yīng)該是 IoT 項(xiàng)目里用得最多的比 QoS 0 多了一倍的握手但可靠性提升非常明顯。3.1 報(bào)文交換流程逐字節(jié)算清一條 QoS 1 消息從發(fā)布端到 broker 的流程如下我做了一個(gè)逐步驟拆解發(fā)送端先給消息分配一個(gè) Packet ID2 字節(jié)從 1 到 65535發(fā)送端發(fā)送 PUBLISH 報(bào)文QoS 位設(shè)為 1Packet ID 填入報(bào)文broker 收到后把消息按訂閱關(guān)系轉(zhuǎn)發(fā)給所有匹配的訂閱端broker 向發(fā)送端回復(fù)一個(gè) PUBACK 報(bào)文確認(rèn)收到發(fā)送端收到 PUBACK 后把這條消息的本地狀態(tài)標(biāo)記為已完成如果發(fā)送端在發(fā)出 PUBLISH 之后等待 PUBACK 期間發(fā)生了超時(shí)或連接斷開發(fā)送端就不知道 broker 到底有沒有收到。此時(shí)協(xié)議允許發(fā)送端在重連后重新發(fā)送一次 PUBLISH并且把 DUP 標(biāo)志置 1表示這是一條可能重復(fù)的報(bào)文。這個(gè) DUP 重發(fā) 的機(jī)制正是 QoS 1 重復(fù)消息的來源。從報(bào)文數(shù)量上看一條 QoS 1 消息發(fā)布和確認(rèn)至少需要 2 個(gè)報(bào)文PUBLISH PUBACK如果發(fā)生超時(shí)重發(fā)那就是 4 個(gè)、6 個(gè)甚至更多。對(duì)于每個(gè)匹配的訂閱端broker 向它轉(zhuǎn)發(fā)時(shí)同樣會(huì)進(jìn)行 QoS 1 的流程因此完整鏈路的報(bào)文量是 2 2N不考慮重發(fā)。3.2 重復(fù)消息為什么不可避免注意上面對(duì)話里第三步的時(shí)序很關(guān)鍵broker 在轉(zhuǎn)發(fā)給訂閱端和回復(fù) PUBACK之間是有順序的。不同 broker 的實(shí)現(xiàn)可能先轉(zhuǎn)發(fā)再回 ACK也可能先回 ACK 再轉(zhuǎn)發(fā)甚至可能是異步并發(fā)。如果 broker 已經(jīng)向訂閱端轉(zhuǎn)發(fā)了 QoS 1 消息但是發(fā)送端斷線了沒收到 PUBACK那發(fā)送端重發(fā)時(shí)訂閱端就會(huì)收到兩條一模一樣的消息。兩條消息的 Packet ID 一樣DUP 標(biāo)志也一樣因?yàn)槎际峭粫?huì)話重發(fā)訂閱端無法簡(jiǎn)單地通過 Packet ID 去重因?yàn)?QoS 1 規(guī)范里壓根沒要求它做去重。這就是至少一次的代價(jià)消息不丟但你得自己處理重復(fù)。最常用的辦法是在應(yīng)用層加業(yè)務(wù)去重比如每條消息帶一個(gè)全局唯一的 messageId 字段訂閱端用一個(gè)滑動(dòng)窗口或者 Redis set 記錄最近處理過的消息 ID。另一個(gè)常規(guī)思路是把消息做成冪等操作例如把溫度設(shè)為 25 度這種賦值型指令天然冪等重復(fù)執(zhí)行兩次結(jié)果一樣而把計(jì)數(shù)器加 1這種非冪等操作就必須配合業(yè)務(wù)去重。3.3 QoS 1 實(shí)際項(xiàng)目中擴(kuò)展出來的花樣實(shí)際項(xiàng)目里我還見過 QoS 1 配 session 過期時(shí)間的方式來做離線消息緩存。比如控制指令場(chǎng)景設(shè)備可能離線一小段時(shí)間如果 cleanSessionfalse 且 session 未過期broker 會(huì)把 QoS 1 消息緩存在會(huì)話里等設(shè)備重連時(shí)再補(bǔ)發(fā)。這比直接用 QoS 2 便宜得多而且大部分業(yè)務(wù)對(duì)重復(fù)指令是可以容忍的——用冪等設(shè)計(jì)把重復(fù)消掉就好。所以 QoS 1 是可靠性和成本折中最均衡的等級(jí)也是我默認(rèn)的起步等級(jí)。4. QoS 2兩輪四次握手為了恰好一次付出多少代價(jià)QoS 2 全稱 Exactly once恰好一次投遞。這是 MQTT 協(xié)議里最復(fù)雜、也是最容易被誤解的部分。很多人以為 QoS 2 就是更可靠一點(diǎn)實(shí)際上它是用一整套握手狀態(tài)機(jī)換來消息既不丟失也不重復(fù)的語義報(bào)文量和協(xié)議復(fù)雜度都遠(yuǎn)超 QoS 0 和 QoS 1。4.1 每一條消息的四步完整往返QoS 2 的發(fā)送端到 broker 這一段協(xié)議規(guī)定的報(bào)文交換流程嚴(yán)格分成兩階段第一階段發(fā)送端發(fā)送 PUBLISH 報(bào)文QoS 位設(shè)為 2攜帶 Packet IDbroker 收到后不會(huì)立刻轉(zhuǎn)發(fā)給訂閱端而是先持久化這個(gè) Packet ID 到會(huì)話狀態(tài)標(biāo)記為已收到但未釋放然后向發(fā)送端回復(fù) PUBREC 報(bào)文第二階段發(fā)送端收到 PUBREC 后知道 broker 已經(jīng)確認(rèn)收到該消息于是發(fā)送一個(gè) PUBREL 報(bào)文表示我這邊已經(jīng)完成發(fā)送流程你可以正式釋放這條消息broker 收到 PUBREL 后才把消息轉(zhuǎn)發(fā)給訂閱端同時(shí)向發(fā)送端回復(fù) PUBCOMP 報(bào)文表示整個(gè) QoS 2 發(fā)送流程關(guān)閉現(xiàn)象上一條 QoS 2 消息從發(fā)送端到 broker 至少要交換 4 個(gè)報(bào)文PUBLISH、PUBREC、PUBREL、PUBCOMP。在最理想情況下是各 1 個(gè)總共 4 個(gè)。如果在某個(gè)環(huán)節(jié)發(fā)生重傳那報(bào)文數(shù)量還會(huì)成倍增加。這個(gè)成本已經(jīng)非常直觀了傳輸 1 條 QoS 2 消息控制報(bào)文的個(gè)數(shù)是 QoS 1 的 2 倍是 QoS 0 的 4 倍以上。4.2 為什么是兩階段提交而不是簡(jiǎn)單 ACK 兩次初學(xué) MQTT 的人都會(huì)有一個(gè)疑問QoS 1 是 PUBLISH PUBACKQoS 2 為什么不能做成 PUBLISH PUBACK 再 PUBACK 一次因?yàn)閮纱为?dú)立的 ACK解決不了重復(fù)問題。如果只用一次 ACK重復(fù)完全靠語義用兩次獨(dú)立 ACK發(fā)送端重發(fā) PUBLISH 時(shí)broker 無法區(qū)分這條 PUBLISH 是全新的還是重發(fā)的也就無法決定到底要不要把消息轉(zhuǎn)發(fā)兩次。QoS 2 的關(guān)鍵設(shè)計(jì)在于中間那個(gè) PUBREL。PUBREL 是一張釋放令牌相當(dāng)于告訴 broker之前的 PUBLISH 我已經(jīng)確認(rèn)你收到了現(xiàn)在我們要完成最后的交接。broker 在收到 PUBLISH 時(shí)記錄 Packet ID但并不會(huì)立即把它投入轉(zhuǎn)發(fā)流程收到 PUBREL 之后這個(gè) Packet ID 的狀態(tài)才從待處理變?yōu)榭赊D(zhuǎn)發(fā)從而保證任何一個(gè) Packet ID 在 broker 側(cè)只會(huì)被消費(fèi)一次。這套機(jī)制和分布式事務(wù)里的兩階段提交思路非常像本質(zhì)上就是用額外的握手換取唯一一次投遞的語義保證。從 broker 側(cè)視角來看還隱含了一個(gè)重要邏輯收到 PUBREC 后broker 一方面要保存 Packet ID另一方面可以回復(fù) PUBREC但是對(duì)外轉(zhuǎn)發(fā)消息必須等到 PUBREL 之后。如果發(fā)送端在發(fā)出 PUBREL 后一直沒收到 PUBCOMP發(fā)送端會(huì)重發(fā) PUBREL而不是重發(fā) PUBLISHbroker 收到重復(fù)的 PUBREL 時(shí)不會(huì)再次轉(zhuǎn)發(fā)消息只會(huì)再次回復(fù) PUBCOMP。這個(gè)細(xì)節(jié)保證了無論如何重試訂閱端最多收到一次。4.3 QoS 2 的狀態(tài)機(jī)異常情況都從哪里來我把 QoS 2 發(fā)送端的典型狀態(tài)變化列一下更直觀發(fā)送端狀態(tài)觸發(fā)事件動(dòng)作待發(fā)送業(yè)務(wù)產(chǎn)生消息發(fā)送 PUBLISH記錄 Packet ID進(jìn)入等待 PUBREC等待 PUBREC收到 PUBREC發(fā)送 PUBREL進(jìn)入等待 PUBCOMP等待 PUBREC超時(shí) / 斷線重連后重發(fā) PUBLISHDUP1仍在等待 PUBREC等待 PUBCOMP收到 PUBCOMP清理 Packet ID流程結(jié)束等待 PUBCOMP超時(shí) / 斷線重連后重發(fā) PUBREL仍在等待 PUBCOMP你可能注意到了等待 PUBREC 階段重發(fā)的是 PUBLISH等待 PUBCOMP 階段重發(fā)的是 PUBREL。這兩次重發(fā)的報(bào)文類型是不同的很多 SDK 的 debug 日志里可以看到同一 Packet ID 的 PUBLISH 和 PUBREL 交替出現(xiàn)如果你不理解狀態(tài)機(jī)很容易誤判成協(xié)議 bug。其實(shí)這正是 QoS 2 為了防重復(fù)做的一個(gè)細(xì)節(jié)只有收到 PUBREC 之后才允許把消息提交給 broker否則無條件重發(fā) PUBLISH而一旦進(jìn)入 PUBREL 階段PUBLISH 已經(jīng)確認(rèn)落地了重發(fā) PUBREL 不會(huì)造成二次轉(zhuǎn)發(fā)。4.4 一個(gè)值得警惕的坑QoS 2 不是端到端恰好一次QoS 2 只保證了發(fā)布端到 broker這一段恰好一次以及broker 到單個(gè)訂閱端這一段恰好一次。如果一條消息從發(fā)布端發(fā)出broker 把它轉(zhuǎn)發(fā)給兩個(gè)訂閱者 A 和 B那么在 A 和 B 那邊各自會(huì)獨(dú)立執(zhí)行 QoS 2 流程。也就是說broker 和 A 之間的 Packet ID 可能與 broker 和 B 之間的完全不同A 和 B 收到消息的時(shí)間也可能差很多。QoS 2 從來不做跨訂閱端的全局去重它只做連接級(jí)的語義保證。更關(guān)鍵的是如果發(fā)布端和 broker 用 QoS 2但 broker 向某個(gè)訂閱端轉(zhuǎn)發(fā)時(shí)訂閱策略或會(huì)話配置把 QoS 降級(jí)了比如訂閱時(shí)請(qǐng)求 QoS 1或者 broker 對(duì) QoS 2 做了下鉆映射那么端到端的語義就不是恰好一次。所以當(dāng)你看到某個(gè)架構(gòu)說自己實(shí)現(xiàn)了端到端 exactly once一定要追問一句發(fā)布端到 broker 是什么等級(jí)broker 到訂閱端是什么等級(jí)兩個(gè)等級(jí)不一致的時(shí)候消息語義以更低的那個(gè)為準(zhǔn)。5. 三張表看懂 QoS 選型性價(jià)比才是第一原則把前三節(jié)的內(nèi)容壓縮一下QoS 等級(jí)的核心差異其實(shí)可以收斂成一張報(bào)文對(duì)照表、一張可靠性對(duì)照表、和一張選型決策表。我在實(shí)際評(píng)審方案時(shí)基本就是拿這三張表逐條過需求。5.1 報(bào)文量與開銷對(duì)照QoS等級(jí)最簡(jiǎn)報(bào)文數(shù)確認(rèn)機(jī)制消息ID超時(shí)重發(fā)動(dòng)作重復(fù)可能性QoS 01PUBLISH無無無沒有重發(fā)邏輯不可能重復(fù)但可能丟失QoS 12PUBLISH PUBACK有有重發(fā) PUBLISHDUP1可能重復(fù)QoS 24PUBLISH PUBREC PUBREL PUBCOMP兩階段確認(rèn)有等待 PUBREC 時(shí)重發(fā) PUBLISH等待 PUBCOMP 時(shí)重發(fā) PUBREL不重復(fù)保證恰好一次這個(gè)表格應(yīng)該是你電腦前貼著的默認(rèn)參考。凡是讓你一把梭直接全上 QoS 2的把這個(gè)表格甩給他看同樣的消息吞吐QoS 2 的協(xié)議開銷是 QoS 1 的兩倍是 QoS 0 的四倍如果消息量大這帶來的 CPU、帶寬、延遲成本會(huì)直接反饋在監(jiān)控曲線上。5.2 典型場(chǎng)景決策參考以下選型建議來自我參與過的幾類真實(shí)項(xiàng)目不是教科書標(biāo)準(zhǔn)答案但大概率能幫你少走彎路業(yè)務(wù)場(chǎng)景消息特征推薦QoS理由傳感器高頻數(shù)據(jù)上報(bào)周期性、容忍少量丟失、量大QoS 0省帶寬、低延遲下游可以做插值或跳變檢測(cè)設(shè)備心跳 / 在線狀態(tài)低頻、需要不丟失QoS 1丟了就誤判離線正常重發(fā)可接受控制指令開關(guān)、調(diào)參低頻、需要必達(dá)QoS 1 業(yè)務(wù)冪等重發(fā)可接受但要做好指令去重計(jì)費(fèi) / 工單 / 支付回調(diào) / 授信變更低頻、語義重大、不允許重復(fù)QoS 2用協(xié)議層保證恰好一次省掉大量對(duì)賬離線設(shè)備指令緩存設(shè)備可能長期離線QoS 1 持久會(huì)話用 session 緩存成本比 QoS 2 低很多要注意的是表格里 QoS 1 業(yè)務(wù)冪等和 QoS 2 是兩條不同的技術(shù)路線。很多時(shí)候 QoS 2 能解決的問題QoS 1 配合冪等 ID 也能兜住只是實(shí)現(xiàn)位置不同QoS 2 把去重做在協(xié)議棧里QoS 1 把去重做在應(yīng)用代碼里。前者省心但費(fèi)帶寬后者省帶寬但費(fèi)開發(fā)。5.3 不要盲目升級(jí) QoS 的另一個(gè)原因有人可能想我都用 QoS 2成本高點(diǎn)就高點(diǎn)至少保險(xiǎn)。但 QoS 2 的恰好一次有一個(gè)前提條件broker 必須能夠維護(hù)每個(gè) Packet ID 的會(huì)話狀態(tài)。如果 broker 宕機(jī)重啟、或者客戶端長時(shí)間離線導(dǎo)致會(huì)話過期那么 QoS 2 的握手狀態(tài)也會(huì)丟失此時(shí)若發(fā)送端重連并重發(fā) PUBRELbroker 可能已經(jīng)不認(rèn)識(shí)這個(gè) Packet ID 了這時(shí)候會(huì)回復(fù)一個(gè) DISCONNECT 或直接當(dāng)作新消息處理。所以 QoS 2 并不等于消息絕對(duì)可達(dá)它只是盡最大努力保證在鏈路和會(huì)話正常的前提下不重不丟。一個(gè)真正可靠的系統(tǒng)還是要靠業(yè)務(wù)層的最終一致性設(shè)計(jì)和重試機(jī)制兜底而不是寄希望于單一協(xié)議等級(jí)。6. 實(shí)際工程里影響 QoS 選擇的隱藏因素我不說你很難注意到上面聊的都是協(xié)議本身的語義但在真實(shí)項(xiàng)目里QoS 最終表現(xiàn)還受一堆外部因素制約。這些因素在報(bào)文數(shù)量層面看不出差異一旦上線都是暗坑。6.1 cleanSession 與持久會(huì)話對(duì) QoS 的影響MQTT 連接由 CONNECT 報(bào)文里的 cleanSession 標(biāo)志控制。如果 cleanSessiontruebroker 不保存任何會(huì)話狀態(tài)客戶端重連后一切清零。此時(shí) QoS 1 或 QoS 2 的重發(fā)機(jī)制依舊存在但當(dāng)客戶端斷開期間到達(dá)的消息broker 不會(huì)緩存直接丟棄。如果 cleanSessionfalsebroker 會(huì)為這個(gè)客戶端保留 session包括未確認(rèn)的 QoS 1 / QoS 2 消息狀態(tài)和離線消息隊(duì)列這才會(huì)出現(xiàn)我們常說的離線消息補(bǔ)發(fā)。所以做選型的時(shí)候要問的不只是 QoS 等級(jí)還有 cleanSession 配置。設(shè)備上報(bào)場(chǎng)景通常 cleanSessiontrue簡(jiǎn)單干脆但控制指令緩存、遺囑消息、狀態(tài)同步這些場(chǎng)景往往要開持久會(huì)話。我見過一個(gè)項(xiàng)目用了 QoS 2 但忘了關(guān) cleanSession結(jié)果設(shè)備一離線消息就丟排查了很久才發(fā)現(xiàn)是會(huì)話狀態(tài)沒保留。協(xié)議等級(jí)選得再高會(huì)話策略不對(duì)等于白搭。6.2 Broker 實(shí)現(xiàn)差異同一 QoS不同表現(xiàn)不同 broker 內(nèi)部實(shí)現(xiàn)方式差別很大直接體現(xiàn)在 QoS 處理路徑上。輕量級(jí) broker 可能把所有消息都放在內(nèi)存里投遞完就刪企業(yè)級(jí) broker 會(huì)對(duì)消息做持久化甚至在 QoS 2 轉(zhuǎn)發(fā)之前寫入消息存儲(chǔ)。如果你的 QoS 2 消息數(shù)量很大broker 的磁盤 IO 就是新的瓶頸。我實(shí)測(cè)過同一組 QoS 2 消息在嵌入式 broker 和企業(yè)級(jí) broker 上的表現(xiàn)吞吐可以差一個(gè)數(shù)量級(jí)原因就是后者多了持久化步驟。另外某些 broker 為了性能會(huì)在轉(zhuǎn)發(fā)時(shí)做 QoS 降級(jí)。比如發(fā)布端用 QoS 2 發(fā)送但某個(gè)訂閱端訂閱主題時(shí)用的是 QoS 0那么 broker 按照取發(fā)布和訂閱 QoS 的較小值這個(gè)規(guī)則只會(huì)用 QoS 0 轉(zhuǎn)發(fā)給該訂閱端。很多人不知道這個(gè)規(guī)則以為發(fā)布端選了 QoS 2 訂閱端就一定能 QoS 2 收到實(shí)際上協(xié)議規(guī)定是 min(pubQoS, subQoS)。所以客戶端訂閱時(shí)的 QoS 也必須按業(yè)務(wù)需求明確設(shè)置否則前面省心后面鬧心。6.3 鏈路層不等于應(yīng)用層TCP 超時(shí)重傳與 MQTT 重發(fā)的疊加MQTT 跑在 TCP 上TCP 自己也有超時(shí)重傳這會(huì)不會(huì)和 MQTT 的 QoS 重發(fā)疊加會(huì)但它們的語義不同。TCP 重傳解決的是字節(jié)流層面的丟包保證整段字節(jié)到達(dá)對(duì)端MQTT 重傳解決的是 broker 應(yīng)用層是否處理完畢。舉一個(gè)極端例子發(fā)送端發(fā)出 QoS 1 的 PUBLISHTCP 層把它拆成幾個(gè) segment 發(fā)出去第一個(gè) segment 到了 broker第二個(gè) segment 丟了TCP 會(huì)重傳丟掉的 segment最終 broker 完整收到 PUBLISH回復(fù) PUBACK。這一過程 TCP 和 MQTT 都在參與但 MQTT 的重發(fā)邏輯不會(huì)介入因?yàn)榘l(fā)送端還沒到超時(shí)條件。如果網(wǎng)絡(luò)質(zhì)量極差TCP 重傳多次仍失敗MQTT 層才會(huì)啟動(dòng)自己的重發(fā)定時(shí)器。所以做測(cè)試時(shí)不要用拔網(wǎng)線來模擬 MQTT 消息丟失那模擬的是連接斷開觸發(fā)的行為往往是會(huì)話重建和 DUP 重發(fā)而不是 TCP 重傳。想要看 MQTT QoS 機(jī)制的真實(shí)表現(xiàn)更好的方式是人為丟包、亂序或延遲注入比如 tc 命令加 netem 模塊這樣可以分別觀察 QoS 1 的 PUBACK 超時(shí)和 QoS 2 的 PUBREC/PUBCOMP 超時(shí)。搞清楚這兩層機(jī)制線上出問題時(shí)才不至于把鍋甩錯(cuò)對(duì)象。6.4 消息體大小對(duì) QoS 開銷的放大效應(yīng)協(xié)議開銷的計(jì)算不應(yīng)該只算報(bào)文個(gè)數(shù)還得乘消息體長度。QoS 0 和 QoS 1 / QoS 2 在 PUBLISH 報(bào)文的可變頭部上差異很小差值基本上就是 0 到 2 字節(jié)的 Packet ID。但是 QoS 1 和 QoS 2 的確認(rèn)報(bào)文 PUBACK / PUBREC / PUBREL / PUBCOMP 都很短固定頭 可變頭不超過 4 字節(jié)。所以當(dāng)消息體很大時(shí)比如固件升級(jí)包分片QoS 1 和 QoS 2 的額外開銷占比反而小當(dāng)消息體很小時(shí)比如開關(guān)狀態(tài)就幾個(gè)字節(jié)QoS 2 的控制報(bào)文開銷占比可能超過 100%。這也是為什么大量小報(bào)文的遙測(cè)場(chǎng)景要堅(jiān)持用 QoS 0哪怕業(yè)務(wù)方一開始喊著不能丟講完成本之后通常也會(huì)接受加業(yè)務(wù)層兜底而不是全局升 QoS。7. 最后的實(shí)操建議和幾個(gè)值得收藏的細(xì)節(jié)寫到這里把我自己項(xiàng)目里沉淀下來的幾條硬經(jīng)驗(yàn)放出來基本上可以直接抄作業(yè)。第一默認(rèn)從 QoS 1 起步再按需降級(jí)或升級(jí)。不要在項(xiàng)目啟動(dòng)會(huì)上拍腦袋定 QoS而是先按消息分類梳理出丟得起 / 丟不起但可重復(fù) / 絕不能重復(fù)三類每一類對(duì)應(yīng) QoS 0、QoS 1 冪等、QoS 2。這套方法我用在十幾個(gè)項(xiàng)目里都穩(wěn)。第二消息體里一定要帶業(yè)務(wù) ID即使你已經(jīng)用了 QoS 2。因?yàn)榭?broker 橋接、版本升級(jí)遷移、以及訂閱端做多副本消費(fèi)時(shí)都可能出現(xiàn)重復(fù)或亂序業(yè)務(wù) ID 是最后的兜底手段。QoS 2 節(jié)省了去重代碼但省不掉業(yè)務(wù)排重字段。第三QoS 2 的 PUBREL 重發(fā)是很常見的現(xiàn)象不要當(dāng)成錯(cuò)誤。正常網(wǎng)絡(luò)抖動(dòng)下每次 QoS 2 消息的傳播都可能伴隨一次 PUBREL 重發(fā)字節(jié)流日志里出現(xiàn) DUP 標(biāo)志是正常行為。真正需要警惕的是 PUBLISH 的 DUP 在 QoS 2 下頻繁出現(xiàn)那說明 PUBREC 遲遲未到大概率是 broker 處理能力存在瓶頸。第四做壓測(cè)時(shí)把報(bào)文數(shù)量統(tǒng)計(jì)帶上。只要在發(fā)布端和訂閱端分別統(tǒng)計(jì)收到的 PUBLISH 數(shù)就能立刻算出實(shí)際 QoS 生效比例。比如發(fā)布端發(fā)了 1000 條 QoS 1訂閱端收了 1012 條那說明至少有 12 條經(jīng)歷了重復(fù)投遞如果訂閱端只收到 958 條那不是 QoS 的錯(cuò)而是會(huì)話配置或 broker 丟消息得另行排查。第五不要在 QoS 2 上強(qiáng)行疊加離線永久緩存。離線緩存場(chǎng)景用 QoS 1 持久會(huì)話就夠了QoS 2 的握手狀態(tài)在長時(shí)間離線后大概率會(huì)失效到時(shí)候反而多出一堆 PUBREL 重發(fā)日志和數(shù)據(jù)殘留。把話說到底QoS 2 是為在線鏈路可靠性設(shè)計(jì)不是為離線海量緩存設(shè)計(jì)。我覺得 MQTT 的 QoS 選型本質(zhì)上是個(gè)系統(tǒng)工程問題協(xié)議只是給了一個(gè)解決可靠性的杠桿而你真正要做的是搞清楚業(yè)務(wù)能容忍什么語義再?zèng)Q定要不要花報(bào)文數(shù)量的成本去換取更嚴(yán)格的語義。報(bào)文數(shù)量會(huì)告訴你每個(gè)選擇的代價(jià)業(yè)務(wù)語義會(huì)告訴你每個(gè)選擇的收益兩者對(duì)齊答案自然就出來了。