MQTT 协议核心机制详解：发布订阅、Topic 与 QoS

本文是「美畅物联」MQTT 5.0 系列文章的第一篇。本系列将从协议基础到平台实践，系统分享我们的技术经验。

前言

物联网平台的核心挑战之一，是在低带宽、高延迟、不稳定的网络环境下，实现海量设备与云端之间可靠、高效的消息通信。MQTT  协议凭借其轻量级、发布/订阅模式和 QoS 保障机制，已成为物联网领域事实上的标准通信协议。

畅云云平台在选型之初对比了 HTTP  轮询、WebSocket、CoAP 和 MQTT 四种方案，最终选择 MQTT 作为核心通信协议，主要基于以下几点考量：

• 协议轻量，固定头部仅 2 字节，适合资源受限的物联网设备
• 发布/订阅模式天然解耦设备与云端，支持灵活的消息路由
• 三级 QoS 保障机制，适应不同可靠性要求的业务场景
• 完善的生态支持，主流语言均有成熟客户端库

本文将从 MQTT 协议最核心的三个机制讲起：发布/订阅模型、Topic 主题与通配符、QoS 服务质量等级。

一、发布/订阅模型

MQTT 采用发布/订阅（Publish/Subscribe）模式，设备与设备之间不直接通信，而是通过 Broker（消息代理）作为中间节点进行消息路由。核心角色包括：

• 发布者（Publisher）：向特定主题（Topic）发布消息的一方，通常是设备或应用服务
• 订阅者（Subscriber）：订阅特定主题、接收消息的一方，可以是设备或后端服务
• Broker（代理）：负责接收发布者的消息，并根据订阅关系将消息分发给匹配的订阅者

这种解耦模式带来三个关键优势：

1. 空间解耦

发布者和订阅者不需要知道彼此的网络地址，只需通过 Topic 关联。在平台中，一个温度传感器只需发布到 factory/workshop1/deviceA/temperature，无需知道谁在消费这个数据——可能是实时大屏 、可能是告警引擎、也可能是一台执行器。

2. 时间解耦

发布者发送消息时，订阅者不一定在线。Broker 可通过 QoS 和会话保持机制缓存消息，等订阅者上线后再投递。这在物联网场景中至关重要——设备经常因网络波动而短暂离线。

3. 同步解耦

发布者发送消息后无需等待订阅者处理，可以立即继续后续操作。一个传感器每秒上报 10 条数据，完全不用等待后端处理完毕。

二、Topic 主题与通配符

Topic 是 MQTT 消息路由的核心标识，采用层级化的字符串表示，用 / 分隔。这种设计类 似于文件系统路径，天然支持层级化的数据组织。

2.1 命名示例

factory/workshop1/deviceA/temperature
factory/workshop1/deviceA/humidity
factory/workshop1/deviceB/temperature
factory/workshop2/deviceA/status

2.2 通配符机制

MQTT 支持两种通配符，但只能出现在订阅端，发布者不能使用通配符：

平台的 Topic 设计实践：

我们采用 {租户ID}/{产品类型}/{设备ID}/{功能类型}/{数据维度} 的命名规范，例如：

tenant001/thermostat/devA001/property/temperature
tenant001/thermostat/devA001/event/overheat_alarm
tenant001/thermostat/devA001/command/set_threshold

这种设计的好处是：

• 第一层做租户隔离，配合 ACL 实现租户间数据隔离
• 层级从粗到细，方便通配符订阅
• 功能类型清晰区分属性上报、事件告警、指令下发

三、QoS 服务质量等级

QoS（Quality of Service）是 MQTT 消息可靠性的核心保障机制，定义了三个等级。在平台的实际业务中，三种 QoS 都有明确的使用场景。

QoS 0 — 最多一次（At most once）

消息最多被发送一次，不保证到达。

• 发送方 PUBLISH 消息后即完成，不等待任何确认
• 消息可能丢失，但不会重复
• 适用场景：温湿度传感器周期性上报，单条丢失可接受，下一周期会补上

QoS 1 — 至少一次（At least once）

消息保证至少到达一次，但可能重复。这是物联网中最常用的 QoS 等级。

• 发送方发送 PUBLISH 后等待接收方返回 PUBACK
• 若超时未收到 PUBACK，发送方会重发
• 接收方可能收到重复消息，业务侧需做幂等处理
• 适用场景：告警事件上报，必须送达，偶发重复不影响业务

QoS 2 — 恰好一次（Exactly once）

消息保证只到达一次，不丢失也不重复，通过四次握手实现：

发送方                        接收方
  │  PUBLISH (Packet ID)  →     │
  │  ←   PUBREC               │
  │  PUBREL                 →    │
  │  ←   PUBCOMP               │

• QoS 2 开销最大（4 次报文交互）
• 适用场景：控制指令下发，重复执行可能导致设备异常

QoS 选型建议

在平台中，约 80% 的消息使用 QoS 1（遥测和告警），约 15% 使用 QoS 0（高频低价值数据），仅约 5% 的关键控制指令使用 QoS 2。

小结

本文介绍了 MQTT 协议的三大核心机制：发布/订阅模型实现了通信解耦，Topic 与通配符提供了灵活的消息路由能力，QoS 等级保障了不同场景下的消息可靠性。

下一篇，我们将深入 MQTT 5.0 的关键新特性，包括原因码、会话过期间隔、主题别名和消息过期间隔，看看这些新特性如何解决 MQTT 3.1.1 在物联网平台实践中的痛点。