Broker
接受客户端连接,评估订阅,并将每条发布的消息路由到匹配的消费者。
MQTT 教程
连接客户端、发布遥测并订阅主题,再通过明确的 QoS、会话、保留消息与安全策略,把这条链路推进到生产级。
MQTT 通过将连接管理、主题匹配和投递协调转移到 Broker,使客户端保持精简。
使用两个终端,以便您可以看到 Broker 如何将发布客户端与订阅者解耦。
使用唯一的 Client ID 连接并先订阅,以便第一个实时消息可见。
使用相同的 Broker 和兼容的凭据,向确切的主题发送一个小的 JSON 有效载荷。
在加入通配符或保留状态前,先确认主题、载荷、QoS、时间戳和客户端身份。
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 -vmosquitto_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 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/#标准 MQTT 发布/订阅模型由 Broker 接收连接、匹配主题并投递消息,客户端之间不会直接发现或路由。
对于频繁可替换的遥测数据,请从 QoS 0 开始;对于必须到达的状态变更或命令,请使用 QoS 1。只有在衡量成本并证明了精确一次要求后,才使用 QoS 2。
不一样。保留的主题只为新的订阅者存储其最新的保留值。当消费者需要历史记录、查询或重放时,请使用数据库或流存储。
端口 1883 通常承载基于 TCP 的纯 MQTT。端口 8883 通常承载基于 TLS 的 MQTT。生产环境的客户端应验证证书并使用加密传输。
使用公共沙箱进行临时测试,然后深入研究生产环境中重要的安全和架构决策。