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