3、MQTT实战入门：Mosquitto搭建、客户端连接、发布与订阅、QoS等级详解
好，咱们进入MQTT的实战环节。
说实话，MQTT这个协议在物联网领域，基本就是事实标准了。我这些年经手的边缘计算项目，十有八九都用它来做设备与服务器之间的数据通道。为什么？因为它轻量、省带宽、还支持断网续传——嗯，这正是咱们这门课的核心。
这一章，咱们不扯虚的。直接上手，把Mosquitto搭起来，然后用客户端连上去，发消息、收消息，再把QoS那几个等级掰开揉碎讲清楚。
3.1 Mosquitto：最轻量的MQTT Broker
Mosquitto是Eclipse基金会下的开源项目。我个人习惯用它来做原型验证，因为它安装简单、配置直观，资源占用极低——在树莓派Zero上都能跑得飞起。
3.1.1 安装Mosquitto
在Ubuntu/Debian系统上，安装就一行命令：
sudo apt update
sudo apt install mosquitto mosquitto-clients -y安装完成后，Broker会自动启动。你可以检查一下状态：
sudo systemctl status mosquitto如果看到 active (running)，恭喜，Broker已经跑起来了。
sudo ufw allow 1883。
3.1.2 配置文件初探
Mosquitto的配置文件在 /etc/mosquitto/mosquitto.conf。默认配置很简单，只允许本地连接。如果你想允许外部设备接入，需要加一行：
listener 1883 0.0.0.0嗯，这里要注意——生产环境中千万别裸奔。后面我们会讲TLS加密和用户名密码认证。
3.2 客户端连接：发布与订阅
Mosquitto自带了两个命令行工具：mosquitto_pub 和 mosquitto_sub。咱们先用它们来感受一下MQTT的发布/订阅模型。
3.2.1 订阅端（Subscriber）
打开一个终端，输入：
mosquitto_sub -h localhost -t "sensor/temperature" -v参数说明：
-h：Broker地址-t：订阅的主题（Topic）-v：显示主题名称
这个终端会一直等待消息。别急，咱们再开一个终端来发消息。
3.2.2 发布端（Publisher）
在另一个终端输入：
mosquitto_pub -h localhost -t "sensor/temperature" -m "25.3"回到订阅端那个终端，你应该能看到：
sensor/temperature 25.3就这么简单。一条消息从发布端发出，经过Broker，到达了订阅端。
3.3 QoS等级详解：从0到2
QoS（Quality of Service）是MQTT最核心的机制之一。说白了，就是消息送达的可靠程度。
MQTT定义了三个等级：
| QoS等级 | 名称 | 语义 | 适用场景 |
|---|---|---|---|
| 0 | 至多一次 | 发完即忘，不确认 | 传感器高频数据（如温度、湿度） |
| 1 | 至少一次 | 保证送达，可能重复 | 设备状态上报 |
| 2 | 恰好一次 | 保证送达且不重复 | 控制指令、计费数据 |
3.3.1 QoS 0：发完即忘
这是最轻量的模式。发布者把消息扔给Broker，Broker转发给订阅者，完事。没有任何确认机制。
为什么会有人用QoS 0？因为快啊！我做过一个项目，设备每秒上报1000个温度点，如果用QoS 2，Broker直接被打爆。这种场景下，丢几个数据点无所谓，但延迟必须低。
mosquitto_pub -h localhost -t "sensor/temperature" -m "25.3" -q 03.3.2 QoS 1：至少一次
发布者发送消息后，Broker会回复一个PUBACK确认包。如果发布者没收到PUBACK，就会重发。
这就保证了消息至少被送达一次。但问题来了——如果PUBACK丢了，发布者重发，订阅者就会收到两条相同的消息。
我在项目中遇到过这种情况：设备上报「门锁已打开」的状态，用了QoS 1。结果网络抖动，订阅端收到了两条相同的指令，导致门锁执行了两次开锁动作。嗯，这就是「至少一次」的代价。
mosquitto_pub -h localhost -t "sensor/temperature" -m "25.3" -q 13.3.3 QoS 2：恰好一次
这是最可靠的等级。它用了四次握手：
- 发布者发送PUBLISH（QoS 2）
- Broker回复PUBREC（收到）
- 发布者回复PUBREL（释放）
- Broker回复PUBCOMP（完成）
这保证了消息既不丢失，也不重复。但代价是延迟高、带宽消耗大。
mosquitto_pub -h localhost -t "sensor/temperature" -m "25.3" -q 23.4 实战：用Python客户端实现断网续传
光用命令行工具不过瘾。咱们写一个Python脚本，模拟设备断网后自动重连并续传数据。
首先安装paho-mqtt库：
pip install paho-mqtt然后写一个带自动重连的发布端：
import paho.mqtt.client as mqtt
import time
def on_connect(client, userdata, flags, rc):
if rc == 0:
print("连接成功")
else:
print(f"连接失败，返回码：{rc}")
def on_disconnect(client, userdata, rc):
print("连接断开，准备重连...")
client = mqtt.Client()
client.on_connect = on_connect
client.on_disconnect = on_disconnect
# 启用自动重连
client.reconnect_delay_set(min_delay=1, max_delay=120)
client.connect("localhost", 1883, 60)
client.loop_start()
# 模拟断网续传
for i in range(10):
ret = client.publish("sensor/data", f"数据包{i}", qos=1)
if ret.rc == mqtt.MQTT_ERR_SUCCESS:
print(f"发送成功：数据包{i}")
else:
print(f"发送失败，缓存中：数据包{i}")
time.sleep(1)
client.loop_stop()这段代码的核心在于 reconnect_delay_set 和 qos=1。当网络断开时，paho客户端会自动缓存未确认的消息，并在重连后重新发送。
3.5 本章小结
咱们这一章，从Mosquitto的安装开始，到命令行工具的发布/订阅，再到QoS三个等级的深入剖析，最后用Python代码实现了断网续传的雏形。
你想想看，MQTT其实不复杂。核心就三件事：Broker、Topic、QoS。把这三样搞明白，大部分物联网通信场景都能应对。
下一章，咱们会深入MQTT的会话机制和遗嘱消息——这两个特性在边缘计算中特别有用。到时候我会分享一个真实项目中的坑，保证让你印象深刻。