📚 课程目录第2章 MQTT协议基础

2. MQTT协议基础

在 Ignition MQTT Transmission 模块中，所有数据最终都通过 MQTT 协议发送到 Broker。如果对 MQTT 的核心概念理解不深，配置时很容易出现“数据发出去了但订阅端收不到”“历史数据丢失”“设备离线后状态无法感知”等问题。本节从发布/订阅模型出发，系统梳理主题、QoS、保留消息、遗嘱消息等关键机制，并结合工业场景说明它们的实际用途。

一、发布/订阅模型：解耦是核心价值

MQTT 采用发布/订阅（Pub/Sub）模型，而不是传统的请求/响应模型。发布者（Publisher）不直接把消息发给订阅者（Subscriber），而是发给 Broker，由 Broker 根据主题把消息分发给所有匹配的订阅者。这种设计带来三个关键特性：

空间解耦：发布者和订阅者互不知道对方地址，只认识 Broker。
时间解耦：双方不必同时在线，Broker 可暂存消息（配合保留消息或持久会话）。
一对多分发：一条消息可被多个订阅者同时接收，适合 SCADA、MES、云平台并行消费。

在 Ignition 中，MQTT Transmission 模块扮演发布者角色，把标签值、报警、历史数据编码后发布到 Broker；而 MQTT Engine 或第三方平台则作为订阅者接收数据。理解这条链路，是排查通信问题的第一步。

二、主题：层级化寻址与通配符

主题（Topic）是 MQTT 的寻址核心，采用斜杠分隔的层级结构，例如 enterprise/site1/lineA/tag/Temperature。主题区分大小写，且不需要预先创建。订阅时可以使用两种通配符：

+：匹配单层，如 enterprise/site1/+/tag/Temperature 可匹配 lineA、lineB。
#：匹配多层，如 enterprise/site1/# 可接收该站点下所有消息。

在 Ignition MQTT Transmission 中，主题通常由“服务器名称/设备名称/标签路径”自动拼接。规划主题命名时，建议把站点、产线、设备、数据类型分层放置，便于后续按层级订阅和权限控制。

工业场景中，主题命名应避免使用中文、空格和特殊字符，推荐使用小写字母、数字和斜杠，保证跨平台兼容性。

三、QoS：消息可靠性的三档选择

QoS（Quality of Service）决定消息投递的可靠程度，共三档：

QoS 等级	投递语义	交互次数	适用场景
QoS 0	最多一次，可能丢失	1 次 PUBLISH	高频遥测、可容忍丢包的实时曲线
QoS 1	至少一次，可能重复	PUBLISH + PUBACK	一般标签值、状态上报
QoS 2	恰好一次，不丢不重	四次握手	计费、批次结果、关键报警

QoS 越高，延迟和带宽开销越大。Ignition MQTT Transmission 允许按标签组或服务器设置 QoS。实践中，普通模拟量可用 QoS 0 或 1，关键报警和批次数据建议 QoS 1 以上。

四、保留消息与遗嘱消息：状态感知的两把钥匙

保留消息（Retained Message）：Broker 会为每个主题保存最后一条保留消息。新订阅者一旦订阅该主题，立即收到这条消息，而不必等待下一次发布。工业场景中，它常用于保存设备当前状态、最新产量、当前配方号，让新上线的看板立刻显示正确值。

遗嘱消息（Will Message）：客户端连接时向 Broker 注册一条遗嘱。当客户端异常断开（网络中断、进程崩溃）时，Broker 自动发布该遗嘱。典型用法是发布 offline 状态到设备状态主题，让监控端及时知道设备失联。

连接时注册遗嘱（示意）：
Will Topic   : enterprise/site1/lineA/status
Will Payload : {"state":"offline","ts":1710000000}
Will QoS     : 1
Will Retain  : true

正常断开时发送：
Topic   : enterprise/site1/lineA/status
Payload : {"state":"online","ts":1710000000}
Retain  : true

遗嘱消息只在“异常断开”时触发。如果客户端主动发送 DISCONNECT，Broker 不会发布遗嘱。因此设备正常下线时，应主动发布 offline 状态并保留。

五、工业场景中的典型应用与误区

在一个汽车零部件产线中，Ignition 通过 MQTT Transmission 把压机温度、节拍、报警发布到 Broker。SCADA 订阅 enterprise/site1/lineA/# 做实时监控，MES 订阅报警主题做工单联动，云平台订阅保留消息获取设备最新状态。三类消费者互不影响，这正是发布/订阅模型的价值。

常见误区包括：

所有主题都用 QoS 2，导致吞吐下降、Broker 压力升高。
保留消息长期不更新，新订阅者看到过期状态。
遗嘱主题与正常状态主题不一致，导致状态判断混乱。
主题层级设计过于扁平，后期无法按站点或产线批量订阅。

复盘时建议检查：主题命名是否分层、QoS 是否与数据重要性匹配、保留消息是否有明确的更新策略、遗嘱消息是否覆盖了所有关键设备。把这四点做扎实，后续 Ignition MQTT Transmission 的配置和排障会顺畅很多。