⚡ MQTT 核心指南

MQTT (Message Queuing Telemetry Transport) — 轻量级发布/订阅消息传输协议，基于TCP/IP，专为物联网 (IoT) 场景设计，解决低带宽、不稳定网络下的设备通信问题。

• 📡 发布/订阅模型，解耦设备与服务
• 🚀 协议开销极小（固定头仅2字节）
• 🔌 支持三个QoS级别，从“最多一次”到“恰好一次”
• 💾 保留消息 & 遗愿消息，提升可靠性
• 🌍 适用：智能家居、车联网、工业监控、移动消息推送

💡 一句话：MQTT = 轻量 + 发布订阅 + QoS + 低功耗，是物联网世界的“HTTP”。

系统架构师学习平台（点击这里进入）

📚 一、核心概念 & 通信模型

概念	说明	类比（消息队列/RabbitMQ）
Broker	服务器，负责接收、过滤、分发消息	类似Kafka Broker/RabbitMQ Server
Publisher	发布者，向特定主题（Topic）发送消息	生产者
Subscriber	订阅者，订阅一个或多个主题，接收匹配的消息	消费者
Topic	UTF-8字符串层级结构（如 home/livingroom/temperature），Broker据此路由	类似Routing Key或队列绑定

工作流程：
① 客户端（发布者或订阅者）连接Broker（默认1883端口，TLS使用8883）。
② 订阅者向Broker订阅主题，如 sensor/+/temperature。
③ 发布者向特定主题发送消息，Broker根据主题过滤并转发给所有匹配的订阅者。
④ 没有直接的点对点连接，发布者和订阅者完全解耦。

✨ 特殊主题通配符

• + 单层通配符
  订阅 home/+/temperature 可匹配 home/kitchen/temperature、home/livingroom/temperature，但不匹配 home/kitchen/coffee/temperature。
• # 多层通配符（必须放在末尾）
  订阅 home/# 可匹配 home/kitchen、home/kitchen/temperature、home/livingroom/light/state 等所有以 home/ 开头的主题。
• $ 系统主题前缀（不参与通配符匹配）
  $SYS/broker/uptime 等Broker内部监控主题。

⚙️ 二、QoS 服务质量 (核心特性)

MQTT提供三个QoS级别，用于在不可靠网络下平衡消息可靠性与传输效率：

级别	名称	机制	消息可能重复	适用场景
0	至多一次 (At most once)	发完即忘，不需要确认，不重试	❌ 不重复，但可能丢失	高频传感器数据（温度、湿度），允许少量丢失
1	至少一次 (At least once)	发送后等待 PUBACK，超时重发	✅ 可能重复	环境控制指令，允许重复但不可丢失
2	恰好一次 (Exactly once)	四次握手 (PUBLISH → PUBREC → PUBREL → PUBCOMP)，去重存储	✅ 不丢失、不重复	支付通知、计费数据、关键告警

📌 重要：QoS是订阅和发布双方协商的，实际生效值为 min(pub_qos, sub_qos)。例如发布用QoS2，订阅用QoS1，最终效果为QoS1。

🔁 会话与持久性

• Clean Session (清理会话)：连接时设置 clean_start=true，Broker不保存该客户端的任何订阅和离线消息。
• 持久会话 (Persistent Session)：clean_start=false，Broker保存客户端所有订阅，当客户端离线时暂存匹配的QoS1/2消息，下次连接时自动推送。
• 会话过期时间：MQTT v5.0 新增 Session Expiry Interval，避免永久堆积离线消息。

🧩 三、保留消息 & 遗愿消息

🏷️ 保留消息 (Retained Message)

发布时设置 retained=true，Broker会为每个主题保留最后一条消息。新订阅者连接后立即收到该消息，无需等待下一次发布。
典型场景：

• 设备状态发布 (home/livingroom/light → "on")，新订阅者接入时马上知道当前灯光状态。
• 环境配置、系统元数据分发。

⚰️ 遗愿消息 (Last Will and Testament, LWT)

客户端连接时设置遗嘱主题和内容。当客户端异常断开（如网络故障、崩溃）时，Broker自动发布这条遗嘱消息到指定主题。
典型场景：

• 设备离线告警：device/offline → "device_id=123, cause=unexpected_disconnect"。
• 监控系统实时感知设备失联。

💡 优雅断开（发送 DISCONNECT 报文）不会触发遗嘱消息。

🔒 四、MQTT v5.0 重要改进（相比v3.1.1）

特性	v3.1.1	v5.0
原因码	只返回成功/失败	详细错误码（如0x91=配额超限）
会话过期	仅依赖clean_session	独立过期时间，支持延迟清理
主题别名	不支持	用整数替代长主题名，节省带宽
用户属性	不支持	类似HTTP头，可携带元数据、链路追踪ID
共享订阅	不支持	$share/<group>/topic，多个订阅者负载均衡
请求/响应	需手动实现关联	原生支持response_topic和correlation_data

🚀 生产建议：新项目优先使用v5.0，尤其是共享订阅和用户属性对水平扩展极有帮助。

🌊 五、MQTT Broker 选型对比

Broker	特点	适用场景
EMQX	高并发（百万连接）、规则引擎、Kafka桥接	企业级IoT平台、车联网
Mosquitto	轻量级、标准C实现、易部署	边缘网关、家庭智能中枢
VerneMQ	高可用集群、多数据中心复制	金融级消息、分布式系统
NanoMQ	超轻量、异步IO、支持边缘计算	ARM设备、资源受限环境

📡 六、MQTT vs 其他常见协议

协议	模型	开销	可靠性	适用场景
MQTT	发布/订阅	极低	3个QoS级别	物联网、低带宽、移动应用
HTTP	请求/响应	较高	基于TCP（依赖TLS）	Web服务、RESTful API
CoAP	请求/响应（类HTTP）	低	基于UDP，支持ACK重传	受限节点网络（6LoWPAN）
AMQP	发布/订阅 + 队列	中高	事务、可靠投递	金融系统、企业消息总线
Kafka	日志/流式	较高	高吞吐、持久化顺序存储	大数据管道、事件溯源

💡 选择口诀：物联网设备窄带宽 → MQTT；简单请求响应 → HTTP；高吞吐日志 → Kafka；资源受限UDP → CoAP。

🐛 七、常见问题 & 实战避坑

🔧 为什么收不到消息？

• ✅ 检查主题是否匹配（包括通配符和$系统主题）。
• ✅ 确认QoS协商结果：实际QoS = min(pub_qos, sub_qos)。
• ✅ 检查Clean Session：若为true且离线，消息不会保存。
• ✅ 检查Broker ACL权限：是否允许发布/订阅该主题。

💥 消息堆积 / 背压控制

• MQTT v5.0 提供接收最大值和配额控制。
• 消费者处理慢时，使用共享订阅将消息分摊给多个订阅者。
• 设置合理的会话过期时间，避免僵尸会话积压离线消息。

🔐 安全加固

• 启用TLS（端口8883） + 客户端证书认证。
• 使用用户名/密码（MQTT v5.0支持增强认证SCRAM）。
• 通过ACL精细控制主题权限（如禁止订阅$SYS/#）。
• 生产环境禁止使用默认的mosquitto/password。

📌 八、速记汇总·一图流

• 🏷️ 模型
  发布/订阅 + 主题层级
• 🎚️ QoS
  0 至多一次 | 1 至少一次 | 2 恰好一次
• 🧩 通配符
  + 单层 | # 多层末尾
• 💾 保留遗嘱
  retained最后消息 | LWT异常断连告警
• 📈 v5.0亮点
  共享订阅 + 主题别名 + 用户属性
• 🔌 典型场景
  传感器采集、远程控制、消息推送、车机通信

🔥 总结：MQTT以极小开销和灵活QoS统治物联网通信；生产环境推荐EMQX + v5.0，务必启用TLS与ACL，善用保留消息和遗嘱消息增强系统可观测性。

适用场景：智能家居控制、车载T-BOX数据上报、工业设备遥测、移动端推送、LoRaWAN/IPC网络、边缘计算节点协同。