MQTT 是一種輕量級消息協議，面向設備、應用、傳感器、網關、雲平臺和控制系統之間的高效通信。它廣泛用於物聯網網絡、遙測系統、智能建築、工業監測、車載平臺、能源系統、家庭自動化、遠程設備管理以及帶寬、電源或網絡穩定性受限的移動應用。

該協議基於發佈/訂閱模型。一個設備並不是把數據直接發送給另一個設備，而是把消息發送到代理服務器。代理再把這些消息分發給已經訂閱匹配主題的客戶端。這種結構讓通信更加靈活、可擴展，也非常適合大量設備彼此不需要知道網絡地址的系統。

換一種方式理解設備消息傳遞

傳統客戶端—服務器通信通常像直接請求與響應：一個客戶端向一個服務器請求信息，服務器再返回結果。MQTT 採用的是另一種思路。設備可以在不知道誰會接收的情況下發布消息，另一個設備也可以在不知道誰會發布的情況下訂閱主題。

這種分離在大型分佈式系統中很有價值。溫度傳感器不需要知道哪個看板、數據庫、移動應用或自動化規則會使用它的數據。它只需要把數據發佈到定義好的主題，代理負責後續分發。

結果就是一種降低設備之間強耦合的通信模式。系統可以在不修改傳感器的情況下新增訂閱者，也可以在不重寫每個應用的情況下新增發佈者。這也是 MQTT 在物聯網和遙測設計中流行的原因之一。

作為消息中心的代理

代理是整個架構中的核心組件。它接受客戶端連接，在需要時驗證客戶端身份，接收發布的消息，將主題與訂閱關係進行匹配，並把消息轉發給正確的訂閱者。

代理可以運行在雲平臺、私有服務器、邊緣網關、工業計算機、嵌入式設備或託管消息服務中。在小型部署中，一個代理可以處理全部流量；在大型部署中，多個代理可能通過集群、橋接、負載均衡或跨區域分佈來協同工作。

代理還控制很多運行行為，例如會話狀態、保留消息、訪問控制、服務質量投遞、保活超時、連接數量限制、主題授權和消息持久化。因此，代理設計會直接影響可靠性、可擴展性和安全性。

連接生命週期

客戶端建立會話

客戶端首先與代理建立網絡連接。MQTT 通常運行在 TCP 之上，安全部署中常使用 TLS 加密。傳輸連接建立後，客戶端發送 CONNECT 報文，其中包含客戶端 ID、認證數據、保活值、會話行為以及可選的遺囑消息設置等信息。

代理檢查連接請求，並用 CONNACK 報文回覆。如果連接被接受，客戶端就可以開始發佈、訂閱、取消訂閱和接收消息。如果連接被拒絕，代理會根據協議版本和配置給出相應原因。

心跳保持鏈路可用

保活機制幫助雙方發現斷開的連接。如果在約定時間內沒有任何數據交換，客戶端會發送 PINGREQ 報文，代理則返回 PINGRESP。

這一點很重要，因為物聯網設備可能運行在不穩定網絡、移動鏈路、Wi-Fi、蜂窩網絡、衛星鏈路或遠程 WAN 路徑上。網絡可能在沒有正常關閉連接的情況下靜默失效，保活機制可以幫助發現這種狀態。

斷開連接與重新連接

客戶端可以通過發送 DISCONNECT 報文正常斷開連接，也可能因為斷電、網絡故障、固件崩潰或信號丟失而意外消失。隨後代理會根據該客戶端配置的會話規則和遺囑消息規則進行處理。

重新連接行為在實際部署中很重要。設備應能優雅地處理網絡中斷，避免過度重連風暴，並按照所需會話策略恢復通信。

主題名稱與消息路由

主題是用於分類消息的文本路徑。主題看起來可以像層級結構，例如 building/floor1/room102/temperature 或 factory/line3/motor7/status。發佈者向主題發送消息，訂閱者從其訂閱的主題接收消息。

良好的主題設計是成功部署中最重要的部分之一。主題名稱應當可預測、可讀，並與真實系統結構保持一致。糟糕的主題設計會讓過濾、權限、監控和長期維護變得困難。

訂閱者可以使用精確主題，也可以使用通配符訂閱。單級通配符可以匹配一個主題層級，多級通配符可以匹配多個層級。通配符適合需要接收大量設備消息的看板、分析平臺、監控工具和管理應用。

發佈與訂閱流程

發佈數據

當客戶端發佈數據時，它會向代理發送 PUBLISH 報文。該報文包括主題名稱、載荷、服務質量等級、保留標誌，以及在所選 QoS 等級需要時使用的報文標識符。

載荷可以包含多種數據格式。它可以是純文本、JSON、二進制數據、傳感器數值、狀態消息、命令、告警、遙測記錄或編碼後的應用數據。MQTT 本身不定義載荷的含義，應用層決定如何組織和解釋它。

接收訂閱

客戶端通過發送帶有一個或多個主題過濾器的 SUBSCRIBE 報文來訂閱。代理返回 SUBACK，並開始按照請求且授予的 QoS 等級向該客戶端投遞匹配消息。

訂閱者可以是看板、數據庫、自動化引擎、雲服務、移動應用、設備控制器或其他現場設備。一條發佈消息可以同時投遞給多個訂閱者。

取消關注

當客戶端不再需要某些消息時，會發送 UNSUBSCRIBE 報文。代理確認請求後，停止轉發匹配主題的消息。

這讓應用可以動態改變數據關注範圍。例如，用戶查看某棟建築時，看板可以訂閱該建築；當用戶切換到另一個站點時，再取消原訂閱。

發佈/訂閱模型允許數據生產者和數據消費者獨立演進，同時由代理管理路由、會話行為和投遞控制。

服務質量等級

QoS 0：最多一次

QoS 0 是最簡單的投遞等級。消息只發送一次，接收方在 MQTT 層不會返回確認。如果消息丟失，協議不會重新傳輸。

這個等級適合頻繁遙測，並且偶爾丟失一次更新可以接受的場景。例如，每隔幾秒發送一次數據的溫度傳感器，通常不需要每一次讀數都必須到達。

QoS 1：至少一次

QoS 1 需要確認。如果發送方沒有收到確認，就會重新傳輸消息。這提高了投遞可靠性，但接收方可能收到重複消息。

使用 QoS 1 的應用應準備好處理重複消息。這常見於告警、狀態變化、命令以及更重視到達而不是完全避免重複的重要遙測。

QoS 2：恰好一次

QoS 2 使用更復雜的握手機制，確保消息在協議層面只投遞一次。它提供最強的投遞保證，但也帶來更多開銷和延遲。

當重複處理會造成不良影響時，可以使用該等級。不過，許多實際部署會選擇 QoS 0 或 QoS 1，因為它們在性能和可靠性之間更平衡。

保留消息與最後已知狀態

保留消息由代理保存為某個主題的最新消息。當新的訂閱者訂閱該主題時，代理會立即發送這條保留消息，使訂閱者能夠看到最近已知狀態。

這對於設備在線狀態、開關狀態、傳感器數值、配置版本、告警狀態或當前運行模式等狀態信息很有用。沒有保留消息時，新訂閱者可能必須等到下一次更新，才能知道當前情況。

保留消息應謹慎使用。它們適合狀態，但不一定適合事件流。一條被保留的“門已打開”事件可能會讓新訂閱者誤以為這仍然為真。狀態主題和事件主題應分別設計。

會話行為與離線投遞

MQTT 支持會話行為，用於決定客戶端斷開並稍後重新連接時會發生什麼。根據協議版本和配置，代理可以為客戶端保存訂閱、排隊消息和會話狀態。

這對會休眠、在不同網絡之間移動或臨時失去連接的設備很有用。當設備重新連接時，只要會話策略和 QoS 規則允許，它就可以繼續接收離線期間排隊的消息。

會話持久性應與設備角色匹配。電池供電的傳感器可能不需要每條命令永久排隊；遠程控制器可能需要排隊的配置更新。過多離線排隊會消耗代理資源，過少則可能導致命令丟失。

用於意外故障的遺囑消息

遺囑消息允許客戶端定義一條消息，當客戶端意外斷開時由代理發佈。這有助於其他系統發現設備故障、網絡丟失或異常關機。

例如，設備可以在 device/123/status 這樣的狀態主題上設置遺囑消息。如果設備斷電且沒有發送正常斷開，代理就會發布配置好的離線消息。

這一功能廣泛用於監控看板、設備健康系統、工業遙測、網關監管和遠程資產管理。它提供了一種簡單方式，把異常斷開暴露給系統的其他部分。

安全與訪問控制

身份認證

代理應在允許訪問之前驗證客戶端身份。認證可以使用用戶名和密碼、客戶端證書、令牌、API 憑據，或與外部身份系統集成。

薄弱的認證可能讓未經授權的設備發佈虛假數據、訂閱敏感主題，或破壞消息環境。

授權

身份確認後，代理應判斷該客戶端可以向哪些主題發佈，以及可以訂閱哪些主題。傳感器不應能向無關設備發佈命令，租戶應用也不應接收其他租戶的數據。

主題級權限在多設備、多站點和多租戶部署中非常關鍵。

加密

TLS 加密保護客戶端與代理之間傳輸中的數據。當消息經過公網、蜂窩網絡、雲連接或不受信任基礎設施時，這一點非常重要。

加密應與證書管理、安全密鑰存儲和謹慎的客戶端配置配合使用。如果憑據暴露在固件或配置文件中，安全傳輸層也無法提供實際保護。

部署模式

設備到雲

在許多物聯網系統中，傳感器和網關把數據發佈到雲端代理。雲應用隨後對數據進行存儲、可視化、分析並觸發動作。這種模式常見於智能建築、能源管理、車隊監控和遠程設備平臺。

主要設計關注點包括安全性、網絡韌性、設備身份、消息量以及雲側擴展能力。

邊緣網關聚合

邊緣網關可以從本地設備收集數據，並把彙總或過濾後的數據發佈到中心代理。它也可以訂閱命令主題，並把指令轉發給本地設備。

這可以減少帶寬佔用、改善本地控制，並允許站點在雲連接不可用時繼續維持部分功能。

站點系統的本地代理

一些部署會在工廠、建築、實驗室、園區或控制室內部使用本地代理。設備和應用在本地交換數據，延遲更低，對外部網絡依賴也更少。

本地代理之後可以把選定數據橋接到雲端或企業平臺。這讓系統設計人員能夠更好地控制數據流和網絡依賴。

在互聯繫統中的應用

工業監測

工廠和公用事業站點使用 MQTT 採集設備狀態、傳感器數據、告警消息、能源數值、溫度讀數、振動數據和生產指標。該協議適合大量設備向上位平臺發送小消息的環境。

工業部署應考慮網絡分段、代理冗餘、QoS 選擇、保留狀態和安全的設備配置。

智能建築

建築系統可以使用該協議連接照明、暖通空調、門禁、佔用傳感器、儀表、電梯、房間面板和看板。主題結構可以映射建築、樓層、房間和設備層級。

這樣可以讓數據更易組織，並幫助自動化規則只訂閱相關事件或狀態。

能源與計量

能源平臺可以使用 MQTT 採集電錶讀數、逆變器數據、電池狀態、負載信息和電網相關遙測。大量設備週期性上報小數值時，輕量消息非常有用。

由於能源系統可能影響計費、控制或安全，認證和消息完整性應被謹慎處理。

聯網車輛與移動場景

車輛平臺、充電站、車隊系統和移動服務可以使用該協議傳輸遙測、位置更新、診斷、告警和遠程控制功能。

移動網絡可能不穩定，因此會話處理、重連邏輯和高效載荷設計都很重要。

消費級與家庭自動化

家庭自動化系統使用 MQTT 連接傳感器、開關、燈具、恆溫器、攝像機、中心網關和自動化規則。發佈/訂閱模型讓一個傳感器事件輕鬆觸發多個動作。

對家庭部署來說，簡單的主題命名和安全的本地代理配置很重要，可以避免混亂和未授權訪問。

性能與可擴展性考慮

消息大小應保持合理。MQTT 對小消息很高效，但並不適合作為超大文件或重媒體流的主要傳輸方式。大載荷會增加代理內存使用、網絡擁塞和處理延遲。

主題設計會影響性能。過度使用寬泛通配符訂閱會增加代理負載，因為大量消息必須被匹配並投遞給許多客戶端。清晰的主題層級有助於系統更可預測地擴展。

連接數量也是一個因素。為成千上萬甚至數百萬客戶端服務的代理，必須處理保活流量、認證、會話狀態、保留消息、排隊消息和網絡限制。擴展可能需要集群、負載均衡、邊緣聚合或主題分區。

QoS 等級也會影響性能。QoS 2 提供更強的投遞語義，但會產生更多報文交換。對於高頻遙測，使用 QoS 0 或 QoS 1 並結合應用層邏輯，通常更實際。

常見設計錯誤

主題命名不清晰

隨機或不一致的主題名稱會讓權限、看板、告警和分析難以管理。大規模部署前應先制定主題規劃。

把保留消息用於事件

保留消息最適合當前狀態。把它們用於一次性事件可能誤導新訂閱者，因為他們可能像剛發生一樣收到舊事件。

沒有重複處理機制

QoS 1 可能投遞重複消息。應用應使用時間戳、消息 ID、序列號或冪等處理，在重複消息可能造成問題時避免影響。

憑據管理薄弱

硬編碼共享密碼、重複使用客戶端 ID、未保護的證書都會帶來嚴重安全風險。每臺設備都應擁有可管理的身份和撤銷路徑。

忽略代理故障

代理是架構中心。如果它發生故障且沒有冗餘或恢復計劃，通信可能停止。關鍵部署應考慮集群、備份代理、橋接設計或本地降級行為。

當主題、會話、QoS、保留狀態、安全和代理容量一起設計，而不是作為孤立設置分別配置時，MQTT 才能發揮良好效果。

維護與監控

運維團隊應監控代理 CPU、內存、連接數量、消息速率、保留消息數量、訂閱數量、排隊消息、認證失敗、掉線連接和網絡延遲。

客戶端健康狀態也應可見。反覆重連、過期會話、重複客戶端 ID、異常發佈速率和異常主題訪問，都可能表示設備故障或安全問題。

配置備份同樣重要。代理設置、訪問控制列表、證書、主題策略、橋接設置和保留狀態行為都應被記錄，並且可以恢復。

常見問題

MQTT 可以通過 WebSocket 工作嗎？

可以。許多代理支持 透過 WebSocket 的 MQTT，讓基於瀏覽器的應用和網頁看板可以通過適合 Web 的傳輸路徑通信。

它適合發送大型視頻或文件內容嗎？

通常不適合作為主要方式。它更適合小消息、遙測、事件、命令和狀態更新。大型文件通常通過其他協議傳輸，並由消息攜帶文件引用。

如果兩個客戶端使用同一個客戶端 ID 會怎樣？

許多代理會在新客戶端使用相同 ID 連接時斷開已有客戶端。唯一的客戶端 ID 對穩定的會話行為很重要。

一個代理可以連接到另一個代理嗎？

可以。根據代理能力，可以使用代理橋接或集群，在站點、區域、邊緣網關和雲平臺之間交換選定主題。

主題名稱應該如何規劃？

使用基於站點、系統、設備、數據類型和功能的一致層級。避免隨機名稱、在主題路徑中放入敏感信息，以及過度依賴寬泛通配符。