第2章 MQTT核心概念

2、MQTT核心概念：发布/订阅模型、主题与通配符、服务质量详解

好，咱们进入正题。这一章讲的是MQTT最核心的几个概念。说实话，我刚开始接触MQTT的时候，觉得它跟传统工业总线完全是两码事。但用久了你会发现，这套机制简直就是为SCADA系统量身定做的。

传统的工业通信，比如Modbus RTU，基本都是主从模式。一个主站轮询，一堆从站应答。这种模式在设备少的时候还行，一旦上了几百个点，轮询周期就长得让人抓狂。

MQTT不一样。它用的是发布/订阅模型。说白了，就是有个中间人——我们叫它Broker。谁想发数据，就往Broker上扔。谁想看数据，就找Broker订阅。发的人和看的人，互相不认识。

我在一个水处理项目中就吃过这个亏。当时用了传统的轮询方式，PLC要采集50多个仪表的数据，一个周期下来快10秒了。后来换成MQTT，每个仪表只管往Broker上发，SCADA服务器订阅就行了。延迟直接降到毫秒级。

这个模型的好处很明显：

我的经验：在SCADA系统中，我习惯把PLC作为发布者，HMI和数据库作为订阅者。这样即使HMI挂了，数据照样能存到数据库里。

主题，就是MQTT里的地址。但它比Modbus的寄存器地址灵活多了。主题是分层的，用斜杠隔开。比如：

factory/line1/temperature
factory/line1/pressure
factory/line2/temperature

你看，这样一组织，数据归属就清清楚楚了。我在做汽车焊装车间的项目时，主题结构是这样的：

plant/shanghai/body_shop/robot_01/status
plant/shanghai/body_shop/robot_01/torque
plant/shanghai/paint_shop/oven_01/temperature

为什么要这么设计？因为后期维护太方便了。哪个车间、哪条线、哪个设备、什么数据，一目了然。

    设计原则：主题命名要像文件路径一样清晰。我建议用「地点/设备/数据类型」的结构，别用无意义的数字编号。

通配符是MQTT最让我喜欢的功能之一。它有两种：

通配符	名称	匹配规则	示例
+	单级通配符	匹配一个层级	factory/+/temperature 匹配 factory/line1/temperature 和 factory/line2/temperature
#	多级通配符	匹配剩余所有层级	factory/# 匹配 factory/line1/temperature 和 factory/line2/robot/status

嗯，这里要注意。通配符只能用在订阅的时候，发布的时候不能用。我曾经有个同事，在发布消息时用了通配符，结果Broker直接报错。他查了半天才反应过来。

实际项目中，通配符能省不少事。比如你要监控整个工厂的温度数据，只需要订阅：

factory/+/temperature

这样所有产线的温度数据就都收到了。不用一条一条去订阅。

避坑指南：我曾经在一个项目中，用#订阅了所有主题。结果Broker上有个调试用的主题，每秒发几千条数据，直接把我的订阅端搞崩了。所以，通配符虽好，但别滥用。尽量精确匹配。

服务质量，简称QoS。它决定了消息传递的可靠性。MQTT定义了三个等级：

QoS等级	名称	可靠性	适用场景
0	至多一次	最低	传感器数据、日志
1	至少一次	中等	控制指令、报警
2	恰好一次	最高	关键数据、交易记录

QoS 0：说白了就是发出去就不管了。性能最好，但可能丢数据。我在做环境监测项目时，温度数据就用QoS 0。因为温度变化慢，丢一两个点无所谓。

QoS 1：保证消息至少到达一次。但可能会重复。比如你发了个「启动设备」的指令，如果网络不好，设备可能收到两次。所以，接收端要做好去重处理。

QoS 2：最可靠，但也最慢。它通过四次握手保证消息不丢不重。我一般只在关键场合用，比如设备急停信号、批次记录等。

我的建议：别一上来就用QoS 2。性能开销大，而且很多场景根本不需要。我见过有人把所有数据都用QoS 2，结果Broker负载过高，反而丢了更多数据。合理选择才是关键。

为什么会这样？因为QoS 2需要额外的确认和存储。你想想看，如果每秒几千条数据都用QoS 2，Broker光处理确认就忙不过来了。

最后总结一下我的经验：

好了，这一章的内容就到这。下一章我们聊聊MQTT的会话机制和遗嘱消息，这两个在工业场景中特别实用。