MQTT 教程
通过端到端跟踪一条消息学习 MQTT
连接客户端、发布遥测并订阅主题,再通过明确的 QoS、会话、保留消息与安全策略,把这条链路推进到生产级。
模型
MQTT 的四个概念
MQTT 通过将连接管理、主题匹配和投递协调转移到 Broker,使客户端保持精简。
接受客户端连接,评估订阅,并将每条发布的消息路由到匹配的消费者。
客户端
任何连接、发布、订阅或执行所有三种操作的传感器、网关、服务、浏览器或应用程序。
主题
一个分层路由,例如 factory/line-1/motor-7/temperature,使发布者与订阅者解耦。
消息
一个有效载荷加上投递设置,例如 QoS、保留、过期和 MQTT 5 属性。
首次端到端实践
发布和接收您的第一条消息
使用两个终端,以便您可以看到 Broker 如何将发布客户端与订阅者解耦。
- 01
启动订阅者
使用唯一的 Client ID 连接并先订阅,以便第一个实时消息可见。
- 02
发布遥测数据
使用相同的 Broker 和兼容的凭据,向确切的主题发送一个小的 JSON 有效载荷。
- 03
验证投递
在加入通配符或保留状态前,先确认主题、载荷、QoS、时间戳和客户端身份。
终端 1 · 订阅
mosquitto_sub \
-h "$MQTT_HOST" -p 8883 \
-u "$MQTT_USERNAME" -P "$MQTT_PASSWORD" \
-i "tutorial-sub-01" \
-t "factory/line-1/motor-7/telemetry" \
-q 1 -v终端 2 · 发布
mosquitto_pub \
-h "$MQTT_HOST" -p 8883 \
-u "$MQTT_USERNAME" -P "$MQTT_PASSWORD" \
-i "tutorial-pub-01" \
-t "factory/line-1/motor-7/telemetry" \
-q 1 \
-m '{"temperature":61.8,"vibration":2.1}'投递语义
根据业务后果选择 QoS
更高的 QoS 会增加握手和状态。它不会自动使应用程序正确。
| QoS 等级 | 投递 | 适用 | 权衡 |
|---|---|---|---|
| QoS 0 | 最多一次;无确认 | 频繁遥测,新读数覆盖旧读数 | 开销最低,但可能丢失 |
| QoS 1 | 至少一次;可能重复 | 状态变更、告警和命令,需幂等消费者处理 | 需要确认和去重 |
| QoS 2 | 在 MQTT 协议层恰好一次 | 少数确实需要恰好一次语义的工作流 | 四方握手,更多状态和更高延迟 |
主题契约
设计主题以实现所有权和授权
主题树即 API。保持其稳定,记录每个层级的文档,并使权限边界清晰可见。
可预测的主题层级结构
factory/{site}/{line}/{device}/{channel}
factory/shanghai/line-1/motor-7/telemetry
factory/shanghai/line-1/motor-7/state
factory/shanghai/line-1/motor-7/command
# Subscribe to telemetry from one line
factory/shanghai/line-1/+/telemetry
# Reserve broad multi-level subscriptions for trusted services
factory/shanghai/#使用稳定的标识符;将显示名称保留在载荷中。
分离遥测、状态和命令的方向。
绝不在主题名称中放置密钥或个人数据。
仅在设备角色确实需要时才授予通配符访问权限。
对破坏性变更明确升级版本,不要临时改名。
记录载荷模式、单位、频率、QoS 和所有权。
生产检查
从成功的演示走向可靠的系统
每个设备一个身份凭证
唯一的凭据使得吊销、轮换、审计和事件范围管理变得容易。
有明确策略的会话
根据预期的网络行为选择会话过期时间、心跳间隔、重连退避和离线队列。
经过验证的容量
对连接、订阅、扇出、载荷大小、保留状态和重连风暴进行负载测试。
可观测的操作
跟踪连接失败、授权拒绝、队列深度、传输延迟和凭据变更。
MQTT 教程常见问题解答
MQTT 没有 Broker 能用吗?
标准 MQTT 发布/订阅模型由 Broker 接收连接、匹配主题并投递消息,客户端之间不会直接发现或路由。
我应该先选择哪个 MQTT QoS?
对于频繁可替换的遥测数据,请从 QoS 0 开始;对于必须到达的状态变更或命令,请使用 QoS 1。只有在衡量成本并证明了精确一次要求后,才使用 QoS 2。
保留消息和消息历史一样吗?
不一样。保留的主题只为新的订阅者存储其最新的保留值。当消费者需要历史记录、查询或重放时,请使用数据库或流存储。
1883 和 8883 端口用于什么?
端口 1883 通常承载基于 TCP 的纯 MQTT。端口 8883 通常承载基于 TLS 的 MQTT。生产环境的客户端应验证证书并使用加密传输。