当前位置：首页 > news >正文

MQTT快速入门

news 2026/8/1 11:17:06

MQTT通信：为什么物联网设备“话少、事多、网还差”，偏偏最适合它？

如果让一台服务器和一万个设备聊天，你会发现一个很残酷的现实：

设备并不会像浏览器那样“老老实实”配合你。

有些设备性能很弱，内存小得可怜；
有些设备网络很差，时断时续；
有些设备甚至挂在 2G、弱 Wi-Fi、蜂窝网络、边缘网关后面；
可业务却一点也不客气:

状态要实时上报
指令要及时下发
掉线还得自动恢复
消息最好别乱丢

这时候，如果你还拿传统“请求一次、响应一次”的思路去硬套，系统很快就会变得又重、又脆、又难维护。

于是 MQTT 出场了。

它不是那种“功能看起来很多”的协议，恰恰相反，它的魅力就在于四个字：

轻、稳、准、够用。

也正因为这样，MQTT 才会成为物联网、智能硬件、车联网、工业采集、边缘通信里出镜率极高的协议之一。

这篇文章，我们不讲空洞概念，直接把 MQTT 最核心的东西讲透：

MQTT 到底是什么
它为什么适合通信场景复杂的设备系统
发布/订阅到底是怎么工作的
QoS 0、1、2 到底有什么区别
它和 HTTP、WebSocket 的思路差在哪
实际项目里什么时候该用 MQTT

看完之后，你至少会真正理解一件事：

MQTT 不是“物联网专属黑话”，而是一套专门为“不稳定通信环境”设计出来的高效消息协议。

先说结论：MQTT 到底是什么？

官方对 MQTT 的定义可以概括为一句话：

MQTT 是一种轻量级、开放、简单、易实现的客户端/服务器发布-订阅消息传输协议。

这句话不长，但信息量很大。

你可以直接拆成四层来理解：

关键词	它的意思
轻量级	报文头小、协议开销低，适合资源受限设备和带宽有限网络
发布/订阅	发送方和接收方不直接强绑定，通过 Broker 中转消息
客户端/服务器	设备或应用作为客户端连接 Broker，Broker 负责路由消息
易实现	很适合嵌入式、IoT、网关、移动端等通信环境复杂的场景

MQTT 最经典的使用环境，就是下面这类场景：

智能家居设备上报状态
工业传感器周期性采集数据
车载设备持续推送遥测信息
服务端向海量终端广播控制指令
弱网环境下保证消息尽可能送达

一张图看懂 MQTT 的工作方式

很多人第一次学 MQTT，会被“主题”“订阅”“Broker”“QoS”这些词绕晕。

其实先别急着记名词，你只要先把下面这张图看懂，整体就通了。

这张图说明了一件特别重要的事：

发布者不需要知道订阅者是谁，订阅者也不需要知道发布者是谁。

大家只需要约定同一个Topic即可。

这就是 MQTT 最核心的设计思想:

解耦。

MQTT 里最重要的 4 个角色

1. Publisher：发布者

发布者负责发送消息，比如：

温湿度传感器上报数据
摄像头上报在线状态
网关上报设备心跳

它只管“发到某个主题”，不需要关心是谁在接收。

2. Subscriber：订阅者

订阅者负责接收自己感兴趣的消息，比如：

手机 App 订阅设备状态
云端平台订阅传感器数据
告警服务订阅故障事件

它只需要订阅某个主题即可。

3. Broker：消息代理

Broker 是 MQTT 的核心枢纽，可以理解为“消息中转站”。

它主要负责：

接收客户端连接
接收发布消息
按主题转发给订阅者
处理会话、保活、QoS、离线消息等能力

常见的 MQTT Broker 有：

EMQX
Mosquitto
HiveMQ
VerneMQ

4. Topic：主题

Topic 是 MQTT 消息路由的关键。

比如：

factory/line1/motor/temp factory/line1/motor/status home/bedroom/light/state car/001/location

你可以把 Topic 理解成“消息的地址”或者“消息的分类路径”。

谁订阅了某个 Topic，谁就能收到这个 Topic 的消息。

为什么 MQTT 比“请求响应”更适合设备通信？

我们先拿最常见的 HTTP 思路做个对比。

对比项	MQTT	HTTP
通信模型	发布/订阅	请求/响应
连接方式	长连接为主	通常短连接或半持久连接
适合场景	高频状态上报、实时消息推送	页面访问、接口调用、资源请求
协议开销	更轻	相对更重
解耦程度	高	低，调用关系更直接
弱网适应性	更好	一般

这也是为什么很多设备系统里会出现一种经典组合：

控制台/管理后台接口用 HTTP
实时状态推送和设备通信用 MQTT

因为它们解决的问题，压根就不完全一样。

HTTP 更像“我主动问你一次，你回我一次”。
MQTT 更像“你只要把消息发到这里，谁关心谁就去收”。

MQTT 最值钱的地方，不是快，而是“省”

很多文章一提 MQTT，就只说“轻量级”“低开销”。

但真正做过设备通信的人会知道，MQTT 真正值钱的地方，不只是快一点，而是它能帮你省掉很多系统复杂度。

它通常能省掉这些麻烦：

发布者和接收者之间的强依赖
设备端频繁轮询服务端的开销
服务端主动追踪每台设备状态的复杂逻辑
在弱网下反复重建请求带来的成本

换句话说：

MQTT 不是单纯“更轻”，而是它把很多通信问题提前抽象掉了。

MQTT 的消息到底怎么走？

下面用一个非常典型的流程来理解。

场景

智能家居里，温度传感器每 5 秒上报一次温度，空调控制器和手机 App 都想看到这个值。

流程

1. 温度传感器连接 Broker 2. 空调控制器订阅 home/livingroom/temp 3. 手机 App 订阅 home/livingroom/temp 4. 传感器向 home/livingroom/temp 发布 26.5 5. Broker 收到后，把消息分发给空调控制器和手机 App

注意看，这个过程中：

传感器不知道 App 存在
App 也不知道传感器的 IP
空调控制器和 App 之间也没有直接耦合

它们都只和 Broker 打交道。

这就是 MQTT 的核心通信模型。

QoS 是 MQTT 最容易被问到的知识点

如果你面试、做项目、看文档，经常会遇到一个词:

QoS

它的全称是Quality of Service，也就是消息服务质量。

你可以简单理解为：

一条消息，Broker 和客户端要“多认真”地保证它送达。

MQTT 里最常见的是 3 个级别。

QoS 级别	含义	特点	适合场景
QoS 0	最多发送一次	不确认，不重发，最快	传感器高频上报、允许偶尔丢包
QoS 1	至少送达一次	会确认，可能重复	普通业务消息、状态同步
QoS 2	只送达一次	流程最严谨，开销最大	不能重复、不能丢失的重要消息

QoS 0：最快，但不保证一定到

这种模式很像：

“我发了，至于你收没收到，我不反复确认。”

适合高频、低价值数据，比如：

温度每秒上报一次
电压采样持续推送
GPS 实时位置流

因为这类数据的特点是：

下一条消息很快就来了，偶尔丢一条问题不大。

QoS 1：至少到一次

这种模式会要求接收方确认。

如果确认没回来，发送方会重发。

好处是更可靠，坏处是可能出现重复消息，所以业务侧要考虑幂等处理。

QoS 2：只到一次

这是 MQTT 最严格的消息保证级别。

它通过更完整的交互流程来避免重复和丢失，但代价就是更复杂、更慢一些。

所以项目里不要一上来就全用 QoS 2。

真正合理的做法是：

按消息价值选择 QoS，而不是盲目选最高级。

保留消息、遗嘱消息、持久会话，这些词到底什么意思？

这几个词特别像“看起来很高级，但第一次读完还是懵”的知识点。

我们一个个讲。

1. Retained Message：保留消息

如果某个 Topic 的最后一条消息被设置为保留消息，那么新订阅者一订阅这个 Topic，就能立刻拿到最近一次的值。

这在设备状态类场景里特别好用，比如：

灯当前是开还是关
门锁当前是锁定还是解锁
设备当前在线还是离线

不然新客户端一连上来，还得等下一次上报才知道状态。

2. Last Will：遗嘱消息

这个名字听起来有点戏剧化，但很实用。

你可以在客户端连接时告诉 Broker：

“如果我异常断开了，你帮我向某个 Topic 发一条消息。”

比如设备掉线了，Broker 可以自动发布：

{"deviceId":"dev001","status":"offline"}

这样监控系统、App、平台服务就能第一时间感知设备异常离线。

3. Persistent Session：持久会话

持久会话的核心价值在于：

客户端临时掉线后，Broker 可以帮你保留一部分会话状态。

比如：

订阅关系不丢
某些 QoS 消息可以在重连后继续投递

这对弱网、移动设备、边缘设备都非常关键。

MQTT 为什么特别适合物联网？

因为物联网场景通常同时满足下面几个特征：

设备多
网络差
带宽贵
消息频繁
终端能力弱
需要低成本持续在线

而 MQTT 几乎就是围绕这些问题设计的。

下面这个表非常能说明问题：

物联网常见问题	MQTT 对应思路
设备资源有限	协议轻量、报文小
网络不稳定	长连接、会话机制、QoS 支持
一条消息要发给很多端	发布/订阅天然适合广播分发
设备和平台解耦困难	Topic 路由减少强依赖
设备掉线难感知	保活机制 + 遗嘱消息

所以你会发现，MQTT 本质上不是“为某个行业定制”的协议，而是：

它非常适合那些通信环境不理想、但消息交互又很频繁的系统。