第4章 MQTT协议详解

第4章 MQTT协议详解：从原理到实战选型

MQTT，全称Message Queuing Telemetry Transport，是物联网领域事实上的“普通话”。

我最早接触MQTT是在2015年做一个智能路灯项目。当时设备端资源极其有限，RAM只有几十KB，HTTP根本跑不动。试了一圈，最后锁定了MQTT。嗯，这一用就是十年。

这一章，我把MQTT的核心知识点掰开揉碎讲清楚。你跟着我的思路走，保证能搞懂。

4.1 MQTT协议原理：轻量级的秘密

MQTT为什么轻量？说白了，它的协议头最小只有2个字节。

对比一下：HTTP请求头动辄几百字节，而MQTT的固定头部就两个字段——消息类型和剩余长度。这在窄带宽、高延迟的物联网场景下，优势是碾压级的。

MQTT基于TCP/IP协议栈。客户端和Broker建立TCP连接后，通过CONNECT报文进行身份认证。认证通过后，双方维持一个长连接。

我个人习惯把MQTT的通信过程总结为三步：

建连：客户端发送CONNECT，Broker回复CONNACK
收发：发布者发PUBLISH，订阅者收消息
保活：双方通过PINGREQ/PINGRESP维持心跳

这里有个坑——我曾经遇到过设备因为NAT超时导致连接断开，但客户端完全不知道。后来我强制把心跳间隔设为30秒，问题就解决了。

核心要点：MQTT的轻量级来源于极简的协议设计。2字节固定头部 + 可变头部 + 负载，构成了一个完整的MQTT报文。

4.2 发布/订阅模型：解耦的艺术

发布/订阅模型，是MQTT最巧妙的设计。

传统客户端-服务器模式，发送方和接收方必须知道对方的存在。而发布/订阅模型引入了一个中间人——Broker。

发布者只管往主题（Topic）上扔消息，订阅者只管从主题上收消息。双方完全解耦。

你想想看，这带来了什么好处？

空间解耦：发布者和订阅者不需要知道对方的IP和端口
时间解耦：发布者离线时，Broker可以缓存消息，等订阅者上线再推送
同步解耦：发布者不需要等待订阅者处理完消息

主题采用层级结构，用“/”分隔。比如：

sensor/temperature/room1
sensor/humidity/room1
actuator/light/room1/switch

订阅时支持通配符：

+：匹配单层。例如 sensor/+/room1 匹配所有room1的传感器
#：匹配多层。例如 sensor/# 匹配所有传感器数据

我在项目中见过有人把主题设计成 device/001/data/temperature，结果订阅时通配符写错了，数据死活收不到。嗯，主题命名规范真的很重要。

我的建议：主题命名遵循“领域/设备类型/设备ID/数据类型”的格式。比如 factory/pump/001/temperature。这样既清晰，又方便权限控制。

4.3 QoS等级：三种可靠性的选择

QoS（Quality of Service）是MQTT保证消息可靠性的机制。一共三个等级。

QoS等级	名称	发送次数	可靠性	适用场景
0	至多一次	1次	最低	传感器数据、日志
1	至少一次	≥1次	中等	控制指令、告警
2	恰好一次	2次	最高	计费、交易

QoS 0：发出去就不管了。性能最好，但可能丢消息。适合温度、湿度这种丢了也无所谓的场景。

QoS 1：保证消息至少到达一次。Broker收到后会回复PUBACK。如果没收到ACK，发布者会重发。但可能导致重复消息。

QoS 2：最可靠，也最慢。通过两次确认（PUBREC/PUBREL/PUBCOMP）保证消息不重不漏。

我曾经在一个智能电表项目里，把计费数据用了QoS 2。结果设备量一上来，Broker的CPU直接飙到90%。后来改成QoS 1 + 业务层去重，性能才稳住。

避坑指南：不要所有消息都用QoS 2。QoS 2的协议开销是QoS 0的5-10倍。能用QoS 0就别用QoS 1，能用QoS 1就别用QoS 2。这是我在生产环境摔出来的经验。

4.4 保留消息与遗嘱消息

这两个特性，是MQTT区别于其他消息协议的精髓。

4.4.1 保留消息

保留消息（Retained Message）是什么？

简单说：发布者发消息时设置保留标志，Broker就会把这条消息存下来。新订阅者上线时，Broker立刻把保留消息推过去。

举个例子：一个温度传感器每隔5分钟上报一次温度。新设备上线订阅 sensor/temperature，如果不用保留消息，它得等最多5分钟才能拿到当前温度。用了保留消息，一订阅就能拿到最新值。

发布保留消息的代码示例：

// MQTT客户端发布保留消息
client.publish("sensor/temperature", "25.3", 1, true);

最后一个参数 true 就是保留标志。

4.4.2 遗嘱消息

遗嘱消息（Will Message），说白了就是设备“临终遗言”。

设备在连接时设置遗嘱主题和遗嘱消息。如果设备异常断开（比如掉电、断网），Broker会代替设备发布这条遗嘱消息。

我在一个冷链监控项目里用过这个特性。冷柜里的温度传感器一旦离线，Broker立刻发布遗嘱消息，运维人员马上收到告警。嗯，这功能救过一批疫苗。

设置遗嘱消息的代码：

// 连接时设置遗嘱
MQTTClient_connectOptions conn_opts = MQTTClient_connectOptions_initializer;
conn_opts.willTopic = "device/001/status";
conn_opts.willMessage = "offline";
conn_opts.willQoS = 1;
conn_opts.willRetained = 0;

关键点：遗嘱消息只在非正常断开时触发。如果设备主动发送DISCONNECT报文，Broker不会发布遗嘱消息。

4.5 Broker选型：EMQX vs Mosquitto

Broker是MQTT架构的核心。选对了，事半功倍；选错了，天天加班。

我主要用过两个：EMQX和Mosquitto。下面是我的真实对比。

特性	EMQX	Mosquitto
开发语言	Erlang/OTP	C
单机并发	百万级	万级
集群支持	原生支持	需第三方
规则引擎	内置	无
插件生态	丰富	较少
资源占用	较高	极低
部署难度	中等	简单
适合场景	大规模生产环境	开发测试/小规模

4.5.1 EMQX：企业级首选

EMQX是我目前在产线上用得最多的Broker。为什么？

高并发：基于Erlang的Actor模型，单机轻松支撑50万并发连接
热升级：升级Broker不需要重启，连接不断
规则引擎：可以直接在Broker层做数据过滤、转换、转发
数据集成：支持直接写入Kafka、MySQL、InfluxDB

部署EMQX很简单：

# Docker一键部署
docker run -d --name emqx -p 1883:1883 -p 8083:8083 -p 8084:8084 emqx/emqx:5.0

4.5.2 Mosquitto：轻量级利器

Mosquitto是Eclipse基金会下的开源项目。特点是轻、小、快。

资源占用极低：树莓派上都能跑
配置简单：一个配置文件搞定
安全性好：原生支持TLS/SSL、ACL权限控制

Mosquitto的配置示例：

# mosquitto.conf
listener 1883
allow_anonymous false
password_file /etc/mosquitto/passwd
acl_file /etc/mosquitto/acl

我个人习惯：开发测试用Mosquitto，生产环境用EMQX。Mosquitto启动快、调试方便；EMQX功能全、性能稳。

选型建议：设备量少于1000台，用Mosquitto就够了。超过1万台，直接上EMQX集群。中间那个区间，看你的预算和运维能力。

4.6 本章知识体系

下面这张图，是我梳理的MQTT核心知识结构。你对照着看，思路会更清晰。

MQTT协议看着简单，但真正用好它，需要对每个细节有深入理解。协议原理是基础，发布/订阅模型是灵魂，QoS是保障，保留消息和遗嘱消息是锦上添花，Broker选型是落地关键。

这五个点串起来，就是一套完整的MQTT知识体系。你在实际项目中遇到问题，回头看看这张图，基本能找到答案。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录