MQTT快速入门

MQTT通信为什么物联网设备“话少、事多、网还差”偏偏最适合它如果让一台服务器和一万个设备聊天你会发现一个很残酷的现实设备并不会像浏览器那样“老老实实”配合你。有些设备性能很弱内存小得可怜有些设备网络很差时断时续有些设备甚至挂在 2G、弱 Wi-Fi、蜂窝网络、边缘网关后面可业务却一点也不客气:状态要实时上报指令要及时下发掉线还得自动恢复消息最好别乱丢这时候如果你还拿传统“请求一次、响应一次”的思路去硬套系统很快就会变得又重、又脆、又难维护。于是 MQTT 出场了。它不是那种“功能看起来很多”的协议恰恰相反它的魅力就在于四个字轻、稳、准、够用。也正因为这样MQTT 才会成为物联网、智能硬件、车联网、工业采集、边缘通信里出镜率极高的协议之一。这篇文章我们不讲空洞概念直接把 MQTT 最核心的东西讲透MQTT 到底是什么它为什么适合通信场景复杂的设备系统发布/订阅到底是怎么工作的QoS 0、1、2 到底有什么区别它和 HTTP、WebSocket 的思路差在哪实际项目里什么时候该用 MQTT看完之后你至少会真正理解一件事MQTT 不是“物联网专属黑话”而是一套专门为“不稳定通信环境”设计出来的高效消息协议。先说结论MQTT 到底是什么官方对 MQTT 的定义可以概括为一句话MQTT 是一种轻量级、开放、简单、易实现的客户端/服务器发布-订阅消息传输协议。这句话不长但信息量很大。你可以直接拆成四层来理解关键词它的意思轻量级报文头小、协议开销低适合资源受限设备和带宽有限网络发布/订阅发送方和接收方不直接强绑定通过 Broker 中转消息客户端/服务器设备或应用作为客户端连接 BrokerBroker 负责路由消息易实现很适合嵌入式、IoT、网关、移动端等通信环境复杂的场景MQTT 最经典的使用环境就是下面这类场景智能家居设备上报状态工业传感器周期性采集数据车载设备持续推送遥测信息服务端向海量终端广播控制指令弱网环境下保证消息尽可能送达一张图看懂 MQTT 的工作方式很多人第一次学 MQTT会被“主题”“订阅”“Broker”“QoS”这些词绕晕。其实先别急着记名词你只要先把下面这张图看懂整体就通了。Publish 到 topic: home/livingroom/tempSubscribe: home/livingroom/tempSubscribe: home/livingroom/tempSubscribe: home/livingroom/temp设备A温度传感器MQTT Broker设备B空调控制器手机App监控界面云端服务告警系统这张图说明了一件特别重要的事发布者不需要知道订阅者是谁订阅者也不需要知道发布者是谁。大家只需要约定同一个Topic即可。这就是 MQTT 最核心的设计思想:解耦。MQTT 里最重要的 4 个角色1. Publisher发布者发布者负责发送消息比如温湿度传感器上报数据摄像头上报在线状态网关上报设备心跳它只管“发到某个主题”不需要关心是谁在接收。2. Subscriber订阅者订阅者负责接收自己感兴趣的消息比如手机 App 订阅设备状态云端平台订阅传感器数据告警服务订阅故障事件它只需要订阅某个主题即可。3. Broker消息代理Broker 是 MQTT 的核心枢纽可以理解为“消息中转站”。它主要负责接收客户端连接接收发布消息按主题转发给订阅者处理会话、保活、QoS、离线消息等能力常见的 MQTT Broker 有EMQXMosquittoHiveMQVerneMQ4. Topic主题Topic 是 MQTT 消息路由的关键。比如factory/line1/motor/temp factory/line1/motor/status home/bedroom/light/state car/001/location你可以把 Topic 理解成“消息的地址”或者“消息的分类路径”。谁订阅了某个 Topic谁就能收到这个 Topic 的消息。为什么 MQTT 比“请求响应”更适合设备通信我们先拿最常见的 HTTP 思路做个对比。对比项MQTTHTTP通信模型发布/订阅请求/响应连接方式长连接为主通常短连接或半持久连接适合场景高频状态上报、实时消息推送页面访问、接口调用、资源请求协议开销更轻相对更重解耦程度高低调用关系更直接弱网适应性更好一般这也是为什么很多设备系统里会出现一种经典组合控制台/管理后台接口用 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 本质上不是“为某个行业定制”的协议而是它非常适合那些通信环境不理想、但消息交互又很频繁的系统。MQTT 和 WebSocket 是什么关系这个问题也非常常见。很多人会误以为它们是竞争关系其实不准确。更合适的理解是WebSocket更偏“传输通道”MQTT更偏“消息协议”也就是说MQTT 可以跑在 TCP 之上也常见于跑在 WebSocket 之上。比如浏览器端接入 MQTT 时很多 Broker 就会提供 WebSocket 接入方式。所以它们不是简单替代关系而是可能叠在一起使用。一个真实项目里MQTT 通常怎么落地下面给你一个很常见的工程结构传感器/设备MQTT Broker手机AppWeb管理后台设备控制服务数据处理服务时序数据库/业务数据库典型流程通常是设备通过 MQTT 上报状态、遥测、告警Broker 把消息分发给数据处理服务数据处理服务做解析、清洗、入库App 或后台订阅相关 Topic实时显示设备状态控制服务向设备下发命令再由设备执行并回传结果这套模式最大的价值在于设备通信层和业务层被自然分开了。MQTT 适合什么不适合什么适合物联网设备通信智能硬件状态上报工业采集与边缘网关实时推送和广播通知弱网环境下的持续连接通信不太适合典型 REST 风格接口调用文件上传下载这类大块数据传输强事务型业务主链路只需要偶发请求、不需要持续在线的简单系统别把 MQTT 神化。它不是“任何实时系统都该上”的银弹而是特别擅长处理“海量终端 高频消息 不稳定网络”这类问题。面试或项目里怎么用一句话讲清 MQTT如果你想用最短的话把 MQTT 解释清楚可以直接说MQTT 是一种轻量级的发布/订阅消息协议通过 Broker 在发布者和订阅者之间转发消息特别适合弱网、低带宽、设备资源受限但需要持续通信的场景。如果还想再加一句工程理解可以补上它的核心优势不是“能通信”而是能在复杂网络环境下以较低成本把通信做得更稳定、更解耦。最后总结很多协议之所以难学不是因为它真的复杂而是因为第一次接触时没有抓住它真正解决的问题。MQTT 也是一样。如果你只把它看成几个名词BrokerTopicQoSRetainWill那它会显得零碎、抽象、难记。但如果你从问题出发你会发现 MQTT 其实很“务实”设备弱、网络差、消息多、还想稳定通信。于是它给出了一套非常工程化的答案用发布/订阅解耦通信双方用 Broker 统一消息流转用 QoS 控制可靠性用会话、保活、遗嘱消息处理不稳定连接这就是 MQTT 能长期活跃在物联网和设备通信领域的原因。说到底它不是最花哨的协议但它确实是非常能打的协议。