📚 课程目录第2章 MQTT协议基础

2、MQTT协议基础：MQTT核心概念、发布/订阅模型、QoS级别、主题与通配符

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是一种基于TCP/IP的轻量级发布/订阅消息协议，由IBM于1999年开发，2014年成为OASIS标准。在Docker容器中部署MQTT Broker（如Eclipse Mosquitto、EMQX）之前，深入理解协议本身是构建可靠测试环境的前提。本章将系统拆解MQTT的四大核心支柱：核心概念、发布/订阅模型、QoS（服务质量）级别以及主题与通配符，并结合后续Docker部署场景给出可操作的判断依据。

上图展示了MQTT协议的核心交互链路：发布者（Publisher）将消息发送到Broker的指定主题（Topic），Broker根据订阅关系将消息副本推送给所有匹配的订阅者（Subscriber）。发布者与订阅者完全解耦，无需知道对方的存在。下面我们逐一深入每个核心概念。

2.1 MQTT核心概念与协议框架

核心原理：Broker、Client、Session与Control Packet

MQTT协议中有三个关键角色：Broker（代理服务器）、Publisher（发布者）和Subscriber（订阅者）。Broker是消息的中转站，负责接收、过滤和分发消息；发布者向特定主题发送消息；订阅者表达对某些主题的兴趣。一个客户端可以同时是发布者和订阅者。

每个客户端与Broker建立连接后，会创建一个会话（Session）。会话可以持久化（Clean Session=0）或非持久化（Clean Session=1）。持久化会话允许客户端断线重连后继续接收离线期间的消息（需配合QoS 1/2），这在Docker容器重启或网络抖动时尤为重要。

协议控制报文（Control Packet）是MQTT通信的基本单位，共14种类型，包括CONNECT（连接）、PUBLISH（发布）、SUBSCRIBE（订阅）、PINGREQ（心跳）等。在Docker部署测试中，我们通常使用mosquitto_pub和mosquitto_sub命令行工具来模拟这些报文。

判断方法：如何识别一个MQTT连接是否正常

当你在Docker容器中运行Broker后，可以通过以下步骤快速验证连接状态：

使用docker logs <container_name>查看Broker启动日志，确认监听1883端口。
在宿主机执行mosquitto_sub -h localhost -t test -v开启订阅。
另开终端执行mosquitto_pub -h localhost -t test -m "hello"发布消息。
观察订阅端是否收到消息，若收到则说明连接、主题匹配均正常。

若连接失败，优先检查Docker端口映射（-p 1883:1883）和防火墙规则。

案例拆解：Docker中Mosquitto的会话保持测试

假设我们需要验证Broker在客户端断线重连后能否恢复会话。使用Docker启动Mosquitto：

docker run -d --name mqtt-test -p 1883:1883 eclipse-mosquitto:2.0

然后订阅端使用持久会话连接：

mosquitto_sub -h localhost -t sensor/data -c -i sub-client-1

此时按Ctrl+C断开订阅端，再发布一条消息：

mosquitto_pub -h localhost -t sensor/data -m "offline-msg" -q 1

重新连接订阅端（使用相同Client ID）：

mosquitto_sub -h localhost -t sensor/data -c -i sub-client-1

如果收到"offline-msg"，说明持久化会话生效。注意：-c参数表示Clean Session为false，-i指定Client ID。若使用不同Client ID，Broker会创建新会话，无法收到离线消息。

常见误区与总结

风险提示：不要混淆Clean Session与消息保留（Retain）。Clean Session控制会话状态是否持久化，而Retain是让Broker保存最后一条消息并发送给新订阅者。两者独立工作，但常被误用。

另一个常见误区是认为Broker会保存所有消息。实际上，MQTT默认不存储消息（除非开启Retain或持久化插件），消息一旦发送给当前在线订阅者即被丢弃。对于需要历史数据的场景，应使用数据库或专门的存储插件。

概念	作用	Docker测试关注点
Broker	消息中转与路由	容器端口映射、日志输出
Client ID	唯一标识客户端	重复ID会导致旧连接被踢下线
Clean Session	会话持久化开关	设为0可接收离线消息
Keep Alive	心跳保活机制	默认60秒，需小于Broker超时设置

2.2 发布/订阅模型：解耦与消息路由

核心原理：基于主题的过滤与扇出

发布/订阅模型的核心优势在于空间解耦（发布者和订阅者互不认识）、时间解耦（无需同时在线）和同步解耦（异步通信）。Broker根据订阅者注册的主题过滤器（Topic Filter）进行消息路由。当发布者发送消息到某个主题时，Broker会查找所有匹配该主题的订阅者，并将消息副本推送给每个订阅者。

这种模型天然支持一对多通信（扇出）。例如，一个温度传感器发布数据到/factory/line1/temp，可以有多个订阅者同时接收：一个用于实时监控，一个用于数据库存储，一个用于告警分析。在Docker环境中，我们可以启动多个订阅容器来模拟这种场景。

操作流程：在Docker中搭建多订阅者测试环境

启动Broker容器：docker run -d --name broker -p 1883:1883 eclipse-mosquitto
启动订阅者容器A：docker run -it --rm eclipse-mosquitto mosquitto_sub -h broker -t 'factory/#' -v
启动订阅者容器B：docker run -it --rm eclipse-mosquitto mosquitto_sub -h broker -t 'factory/+/temp' -v
发布消息：docker run --rm eclipse-mosquitto mosquitto_pub -h broker -t factory/line1/temp -m "23.5"

注意：容器间通信需使用--link或自定义网络。推荐创建Docker网络：docker network create mqtt-net，然后所有容器加入该网络。

案例拆解：工厂车间监控系统的主题设计

假设一个工厂有3条生产线，每条线有温度和湿度传感器。合理的主题层级设计如下：

factory/
  line1/
    temperature
    humidity
  line2/
    temperature
    humidity
  line3/
    temperature
    humidity

监控系统订阅factory/#获取所有数据；告警服务订阅factory/+/temperature只处理温度；生产线1的本地看板订阅factory/line1/#。这种设计使得权限控制和数据过滤变得简单。在Docker中，我们可以为不同订阅者分配不同容器，每个容器只订阅所需主题，实现逻辑隔离。

常见误区与总结

经验提醒：主题层级不要设计过深（建议不超过5层），否则会降低Broker的匹配效率。同时，避免在主题中使用空格或中文，保持ASCII字符集。

另一个误区是认为订阅者会收到自己发布的消息。实际上，MQTT协议规定Broker不会将消息转发给发布者本身（除非发布者同时订阅了该主题）。这在测试时容易造成困惑，需特别注意。

2.3 QoS级别：消息投递的可靠性保障

核心原理：三种QoS的语义与开销

MQTT定义了三个QoS级别，控制消息从发布者到订阅者的投递保证：

QoS 0（最多一次）：消息尽力发送，不确认，可能丢失。适用于传感器高频数据，丢失一帧无影响。
QoS 1（至少一次）：保证消息到达，但可能重复。通过PUBACK确认机制实现，适用于需要确认但允许重复的场景。
QoS 2（恰好一次）：保证消息不重不漏，通过四步握手（PUBLISH→PUBREC→PUBREL→PUBCOMP）实现。适用于计费、订单等关键业务。

QoS级别是端到端的，即发布者与Broker之间的QoS和Broker与订阅者之间的QoS可以不同。Broker会降级处理：如果发布者使用QoS 2，但订阅者只请求QoS 0，则Broker以QoS 0转发。

判断方法：如何选择合适的QoS

场景	推荐QoS	理由
环境温度采集（每秒1次）	QoS 0	数据冗余高，丢包可接受
设备状态变更（开关）	QoS 1	需确保状态更新，重复可容忍
支付指令/远程控制	QoS 2	必须精确一次，避免重复扣款
离线消息补发	QoS 1/2	需持久化会话配合

案例拆解：QoS降级与消息重复的实测

在Docker中启动Mosquitto，开启调试日志：

docker run -d --name mqtt-qos -p 1883:1883 -v $(pwd)/mosquitto.conf:/mosquitto/config/mosquitto.conf eclipse-mosquitto

mosquitto.conf内容：

listener 1883
log_type all

订阅端使用QoS 0：mosquitto_sub -h localhost -t test -q 0 -v

发布端使用QoS 2：mosquitto_pub -h localhost -t test -m "hello" -q 2

观察Broker日志，可以看到Broker收到QoS 2的PUBLISH，但向订阅者发送时降级为QoS 0。这验证了QoS的端到端特性。若订阅端使用QoS 1，则可能收到重复消息（当Broker重发PUBLISH时）。

常见误区与总结

风险提示：QoS 2并非绝对可靠，如果Broker在四步握手中崩溃，消息仍可能丢失。对于极端重要数据，应结合应用层确认机制。

另一个误区是认为提高QoS会线性增加性能开销。实际上，QoS 2的开销远大于QoS 1（约4倍报文交互），在Docker容器中大量使用QoS 2可能导致Broker吞吐量下降。建议仅在必要时使用QoS 2。

2.4 主题与通配符：灵活的消息过滤机制

核心原理：主题层级与通配符匹配规则

主题（Topic）是UTF-8字符串，使用正斜杠/分隔层级，例如factory/line1/temperature。主题过滤器（Topic Filter）可以包含通配符：

+（单层通配符）：匹配一个层级。例如factory/+/temperature匹配factory/line1/temperature和factory/line2/temperature，但不匹配factory/line1/humidity。
#（多层通配符）：匹配剩余所有层级，必须放在最后。例如factory/#匹配factory/line1、factory/line1/temperature等所有以factory/开头的主题。

通配符只能用于订阅，不能用于发布。此外，主题以/开头时，第一个层级为空字符串，例如/factory与factory是不同的主题。

操作流程：验证通配符匹配规则

# 订阅所有工厂数据
mosquitto_sub -h localhost -t 'factory/#' -v
# 订阅所有line1的数据
mosquitto_sub -h localhost -t 'factory/line1/#' -v
# 订阅所有生产线的温度
mosquitto_sub -h localhost -t 'factory/+/temperature' -v
# 发布测试消息
mosquitto_pub -h localhost -t factory/line1/temperature -m "25.1"
mosquitto_pub -h localhost -t factory/line2/humidity -m "60%"

观察不同订阅端收到的消息，可以直观理解通配符的匹配行为。注意+只匹配一层，而#匹配零层或多层。

案例拆解：智能家居主题设计的最佳实践

考虑一个智能家居系统，包含客厅、卧室、厨房三个区域，每个区域有灯和空调。推荐主题结构：

home/
  livingroom/
    light
    ac
  bedroom/
    light
    ac
  kitchen/
    light
    ac

手机App订阅home/#获取所有状态；语音助手订阅home/+/light控制所有灯；区域控制面板订阅home/livingroom/#。这种设计支持灵活的权限控制：可以为不同设备分配不同主题前缀，通过Broker的ACL（访问控制列表）限制发布/订阅权限。

常见误区与总结

经验提醒：主题命名应遵循"从泛到专"的顺序，例如区域/设备/属性，便于使用通配符进行批量操作。避免在主题末尾添加动态ID（如device/12345），否则无法使用#高效匹配。

一个常见误区是认为+可以匹配多层。实际上+严格匹配一层，home/+/light不会匹配home/livingroom/floor1/light。另一个误区是忽略主题的权限控制，在Docker部署中，应配置Mosquitto的acl_file来限制不同客户端的主题访问范围。