第1章 MQTT基础回顾

一、MQTT基础回顾：协议概述、发布/订阅模型、主题与通配符、QoS等级详解

各位同学，欢迎来到《MQTT遗嘱消息与保留消息应用实战》的第一章。

在正式开始之前，我想先聊聊MQTT这个协议。说实话，我最早接触MQTT是在做智能家居项目的时候。当时设备端资源紧张，HTTP太重了，WebSocket又太复杂。后来发现MQTT，简直像发现了新大陆——轻量、可靠、还支持双向通信。嗯，今天我们就从最基础的东西开始，把地基打牢。

MQTT，全称Message Queuing Telemetry Transport，翻译过来就是「消息队列遥测传输」。名字挺长，但说白了，它就是一个轻量级的发布/订阅消息协议。

为什么说它轻量？我举个例子。一个最简单的MQTT控制报文，头部只有2个字节。相比之下，HTTP的头部动不动就几百字节。你想想看，在那些只有几十KB内存的嵌入式设备上，这个差距有多明显。

MQTT有几个核心特点：

我个人习惯把MQTT比作一个「消息邮局」。你不需要知道信送到谁手里，只需要把信交给邮局（Broker），邮局会帮你分发给所有订阅了该地址的人。这个模型，就是发布/订阅。

发布/订阅模型，是MQTT最核心的设计思想。它把通信双方彻底解耦了。

在MQTT的世界里，有三个角色：

发布者不需要知道谁在订阅，订阅者也不需要知道谁在发布。它们只跟Broker打交道。我在项目中遇到过很多新手，总想搞明白「消息到底发给谁了」。其实没必要，你只要把消息发到正确的主题上，Broker会帮你搞定一切。

核心要点：发布/订阅模型的最大优势就是解耦。发布者和订阅者在时间、空间、流量上完全解耦。哪怕订阅者不在线，Broker也可以暂存消息（取决于QoS和配置）。

主题，就是MQTT中的「地址」。发布者把消息发到某个主题，订阅者订阅某个主题，Broker负责匹配。

主题的格式是分层的，用斜杠/分隔。比如：

home/livingroom/temperature
factory/line1/machine01/status
sensor/+/temperature

这里有个重要的概念——通配符。MQTT支持两种通配符：

通配符	含义	示例
`+`	匹配单层主题	`sensor/+/temperature` 匹配 `sensor/room1/temperature`
`#`	匹配多层主题	`home/#` 匹配 `home/livingroom/temperature`

注意：通配符只能用在订阅时，不能用在发布时。我曾经见过有人试图用通配符发布消息，结果Broker直接拒绝了。记住，发布者必须指定一个明确的主题。

另外，主题的命名有一些约定俗成的规则。我个人建议：

QoS，全称Quality of Service，服务质量等级。MQTT定义了三个等级，分别对应不同的可靠性要求。

QoS等级	含义	可靠性	适用场景
0	至多一次	最低	传感器数据，丢失一两次没关系
1	至少一次	中等	控制指令，必须到达但可重复
2	恰好一次	最高	计费、交易等关键数据

QoS 0：说白了就是「发出去就不管了」。Broker收到消息后不会回复确认，发布者也不知道消息到底到没到。效率最高，但可能丢消息。我在做环境监测项目时，温度数据就用QoS 0，因为每秒都在上报，丢一两个没关系。

QoS 1：保证消息至少到达一次。Broker收到后会回复一个PUBACK。如果发布者没收到确认，就会重发。但问题来了——可能重复。你想想看，如果控制灯的指令重复了，灯就会闪一下。所以QoS 1适合那些「重复了也没事」的场景。

QoS 2：最严格，也最复杂。它通过两次确认（PUBREC、PUBREL、PUBCOMP）来保证消息恰好到达一次。开销最大，但最可靠。我曾经在金融支付项目中用过QoS 2，每一笔交易都不能多也不能少。

避坑指南：我曾经犯过一个错误——把所有消息都设成QoS 2。结果设备性能直线下降，Broker也扛不住。后来才明白，QoS的选择要权衡。能用0就别用1，能用1就别用2。别为了「保险」而牺牲性能。

另外，QoS还有一个重要的点——发布者和订阅者的QoS可以不同。比如发布者用QoS 1发消息，订阅者用QoS 0订阅，那么Broker会以较低的QoS 0转发给订阅者。这个规则叫「降级转发」，记住就行。

好了，这一章我们回顾了MQTT的基础知识。从协议概述到发布/订阅模型，从主题通配符到QoS等级，这些都是后续学习遗嘱消息和保留消息的必备基础。

下一章，我们会正式进入遗嘱消息的实战。到时候我会分享一个真实的项目案例——设备异常断电后，如何通过遗嘱消息通知运维人员。嗯，那个案例挺有意思的，到时候细说。

今天就到这里。记住，基础不牢，地动山摇。把这一章的内容吃透了，后面的路就好走了。