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 对稳定的会话行为很重要。

一个代理可以连接到另一个代理吗？

可以。根据代理能力，可以使用代理桥接或集群，在站点、区域、边缘网关和云平台之间交换选定主题。

主题名称应该如何规划？

使用基于站点、系统、设备、数据类型和功能的一致层级。避免随机名称、在主题路径中放入敏感信息，以及过度依赖宽泛通配符。