什么是 MQTT？物联网设备如何通过 MQTT 连接云平台

在上一篇文章中，我们介绍了物联网中常见的通信协议，包括 MQTT、HTTP 和 Modbus，并简单对比了它们的应用场景。

其中，MQTT 是物联网系统中非常常见的一种通信协议。很多 IoT 平台、工业网关、智能设备、传感器系统都会支持 MQTT。

那么问题来了：

MQTT 到底是什么？
为什么物联网设备经常使用 MQTT？
设备又是如何通过 MQTT 连接云平台的？

本文将从入门角度介绍 MQTT 的基本概念、通信流程和典型应用场景，帮助初学者理解 MQTT 在物联网系统中的作用。

---

一、MQTT 是什么？

MQTT，全称是 Message Queuing Telemetry Transport，中文通常称为 消息队列遥测传输协议。

它是一种轻量级的消息传输协议，特别适合物联网场景。

简单来说，MQTT 的作用是：

让设备能够以较小的通信开销，把数据发送到服务器或云平台，也可以接收平台下发的控制指令。

在物联网系统中，很多设备需要长期在线，并且持续上传数据，例如：

• 温湿度传感器上传环境数据；
• 智能电表上传电压、电流、功率；
• 工业网关上传 PLC 或仪表数据；
• 车辆设备上传 GPS、速度、状态信息；
• 智能家居设备接收开关控制命令。

这些设备通常具有以下特点：

• 设备数量多；
• 网络环境可能不稳定；
• 带宽可能有限；
• 有些设备功耗较低；
• 需要长时间运行；
• 需要实时上传数据或接收控制指令。

MQTT 正是为这类场景设计的，因此它在物联网领域非常常见。

---

二、为什么物联网中常用 MQTT？

相比 HTTP，MQTT 更适合很多物联网设备通信场景。

主要原因有以下几点。

1. 协议轻量，通信开销小

MQTT 的协议头比较小，传输数据时额外开销较低。

对于一些低带宽、弱网络环境，例如 4G、NB-IoT、LoRa、卫星通信等场景，通信开销越小越有优势。

例如，一个温度传感器每隔 10 秒上传一次数据，如果设备数量很多，长期运行下来，通信流量和服务器压力都会变得很明显。

MQTT 轻量级的特点可以减少网络资源消耗。

---

2. 支持长连接

MQTT 通常基于 TCP 长连接。

设备连接到 MQTT 服务器后，可以保持在线状态。只要连接没有断开，设备和平台之间就可以持续进行消息传输。

这对于物联网设备非常重要。

例如：

• 设备可以实时上传数据；
• 平台可以及时下发控制命令；
• 服务器可以判断设备是否在线；
• 设备断线后可以自动重连。

---

3. 支持发布/订阅模式

MQTT 最大的特点是采用 发布/订阅模式。

设备不需要直接把消息发送给某个具体应用，而是把消息发布到某个主题 Topic。

订阅这个 Topic 的客户端，都可以收到消息。

这种方式非常适合物联网系统中的多方协作。

例如：

设备发布温度数据 → MQTT Broker → 云平台、数据库服务、告警服务、大屏系统都可以订阅

这样可以降低系统之间的耦合度。

---

4. 适合不稳定网络

很多物联网设备部署在现场环境中，例如工厂、变电站、车辆、户外设备、农业大棚等。

这些环境中的网络可能会出现：

• 信号弱；
• 延迟高；
• 偶尔断线；
• 带宽有限；
• 设备频繁重启。

MQTT 支持心跳检测、断线重连、会话保持、QoS 消息质量等级等机制，更适合这种不稳定网络环境。

---

5. 支持双向通信

MQTT 不仅可以用于设备上传数据，也可以用于平台下发指令。

例如：

设备上传数据：

设备 → 云平台

平台下发控制命令：

云平台 → 设备

这对于远程控制场景非常有用，例如：

• 远程开关设备；
• 修改设备参数；
• 下发采集周期；
• 控制继电器；
• 远程重启设备；
• 发送告警确认指令。

---

三、MQTT 的基本架构

MQTT 通信中通常有三个核心角色：

角色	说明
MQTT Client	MQTT 客户端，可以是设备、网关、服务器或应用
MQTT Broker	MQTT 消息服务器，负责接收和转发消息
Topic	主题，类似消息的地址或分类

MQTT 的基本架构如下：

设备 Client  →  MQTT Broker  →  平台 / 应用 Client

也可以理解为：

发布者  →  Broker  →  订阅者

其中，Broker 是 MQTT 系统的核心。

---

四、MQTT Client 是什么？

MQTT Client 指的是连接到 MQTT Broker 的客户端。

在物联网系统中，Client 可以是：

• 传感器设备；
• 工业网关；
• 边缘计算设备；
• 云平台服务；
• 数据处理程序；
• 手机 App；
• Web 后台；
• 测试工具，例如 MQTTX、MQTT.fx 等。

只要它能够连接 MQTT Broker，并进行发布或订阅操作，就可以称为 MQTT Client。

例如，一个工业网关采集到现场设备数据后，可以作为 MQTT Client 将数据发布到 Broker。

工业网关 Client → MQTT Broker → 云平台

云平台也可以作为 MQTT Client 订阅设备数据。

---

五、MQTT Broker 是什么？

MQTT Broker 可以理解为 MQTT 消息服务器。

它的主要作用是：

• 接收客户端连接；
• 验证客户端身份；
• 接收客户端发布的消息；
• 根据 Topic 将消息转发给订阅者；
• 管理客户端连接状态；
• 处理 QoS、保留消息、遗嘱消息等机制。

简单来说：

Broker 就像一个消息中转站。设备把消息发给 Broker，Broker 再把消息转发给需要的人。

例如：

温度传感器发布数据到 Broker
云平台订阅对应 Topic
Broker 将温度数据转发给云平台

常见的 MQTT Broker 有：

• Mosquitto；
• EMQX；
• HiveMQ；
• VerneMQ；
• 云平台自带 MQTT Broker，例如阿里云 IoT、腾讯云 IoT、AWS IoT、Azure IoT Hub 等。

在学习阶段，可以使用 Mosquitto 或 EMQX 搭建本地 MQTT Broker 进行测试。

---

六、Topic 是什么？

Topic 是 MQTT 中非常重要的概念。

Topic 可以理解为消息的“地址”或“分类”。

设备发布消息时，需要指定一个 Topic。
其他客户端订阅这个 Topic 后，就可以收到对应消息。

例如，一个设备上传温度数据，可以发布到：

factory/device001/temperature

如果云平台订阅了这个 Topic，就可以收到该设备的温度数据。

---

1. Topic 的层级结构

MQTT Topic 通常使用 / 表示层级结构。

例如：

factory/workshop01/device001/temperature

这个 Topic 可以理解为：

工厂 / 车间01 / 设备001 / 温度

再比如：

building/floor01/room101/humidity

可以理解为：

楼宇 / 1楼 / 101房间 / 湿度

这种层级结构非常适合管理大量设备。

---

2. Topic 命名示例

不同场景下，Topic 命名可以不同。

例如，智能家居场景：

home/livingroom/light/status
home/livingroom/light/control
home/bedroom/temperature

工业物联网场景：

factory/line01/plc001/data
factory/line01/plc001/alarm
factory/line01/gateway001/status

车辆联网场景：

vehicle/truck001/gps
vehicle/truck001/speed
vehicle/truck001/alarm

设备上云场景：

device/device001/property/post
device/device001/event/post
device/device001/command/reply

---

3. Topic 的设计建议

在实际项目中，Topic 设计很重要。

建议 Topic 命名遵循以下原则：

• 层级清晰；
• 便于区分设备；
• 便于区分数据类型；
• 避免过长；
• 不要包含敏感信息；
• 命名规则要统一；
• 上行数据和下行指令最好分开。

例如：

设备数据上报：
iot/device001/data

设备状态上报：
iot/device001/status

平台命令下发：
iot/device001/command

设备命令回复：
iot/device001/reply

这样结构清晰，后期维护也更方便。

---

七、Payload 是什么？

Payload 是 MQTT 消息中的实际内容。

Topic 表示消息发送到哪里，Payload 表示发送什么内容。

例如：

Topic: factory/device001/temperature
Payload: {"temperature": 28.5}

其中：

• factory/device001/temperature 是 Topic；
• {"temperature": 28.5} 是 Payload。

Payload 可以是多种格式，例如：

• JSON；
• 字符串；
• 二进制数据；
• XML；
• 自定义格式。

在物联网系统中，JSON 是比较常见的数据格式。

例如：

{
  "device_id": "device001",
  "timestamp": 1714300000,
  "temperature": 28.5,
  "humidity": 65,
  "status": "online"
}

这条消息表示设备 device001 上传了一组数据，包括时间戳、温度、湿度和状态。

---

八、发布和订阅是怎么工作的？

MQTT 的核心机制是 发布 Publish 和 订阅 Subscribe。

1. 发布 Publish

发布就是客户端向某个 Topic 发送消息。

例如，设备上传温度数据：

Publish Topic: factory/device001/temperature
Payload: {"temperature": 28.5}

设备发布后，消息会先到 MQTT Broker。

---

2. 订阅 Subscribe

订阅就是客户端告诉 Broker：

如果某个 Topic 有新消息，请转发给我。

例如，云平台订阅温度数据：

Subscribe Topic: factory/device001/temperature

当设备向这个 Topic 发布消息时，Broker 就会把消息转发给云平台。

---

3. 发布/订阅完整流程

完整流程如下：

1. 设备连接 MQTT Broker
2. 云平台连接 MQTT Broker
3. 云平台订阅 Topic：factory/device001/temperature
4. 设备发布温度数据到该 Topic
5. Broker 收到消息
6. Broker 将消息转发给订阅该 Topic 的云平台
7. 云平台收到数据并进行存储、显示或告警判断

可以用下面的结构表示：

设备发布数据
    ↓
MQTT Broker
    ↓
云平台订阅并接收数据

---

九、MQTT 通配符

在 MQTT 中，订阅 Topic 时可以使用通配符。

常见通配符有两个：

通配符	含义
+	匹配单层 Topic
#	匹配多层 Topic

---

1. 单层通配符 +

+ 用于匹配某一层 Topic。

例如：

factory/+/temperature

它可以匹配：

factory/device001/temperature
factory/device002/temperature
factory/device003/temperature

但不能匹配：

factory/workshop01/device001/temperature

因为中间多了一层。

---

2. 多层通配符 #

# 用于匹配多层 Topic，通常放在 Topic 的最后。

例如：

factory/#

它可以匹配：

factory/device001/temperature
factory/device001/humidity
factory/workshop01/device001/status
factory/workshop01/line02/plc001/data

如果平台想订阅某个工厂下所有设备数据，可以使用类似 Topic：

factory/#

---

3. 通配符使用建议

通配符很方便，但在实际项目中要谨慎使用。

如果订阅范围太大，可能会导致：

• 接收消息过多；
• 平台处理压力增加；
• 数据权限不清晰；
• 调试困难。

因此，建议根据实际业务合理设计 Topic 和订阅范围。

---

十、QoS 是什么？

QoS，全称是 Quality of Service，即服务质量。

MQTT 支持三种 QoS 等级，用来控制消息传输的可靠性。

QoS 等级	含义	特点
QoS 0	最多发送一次	不保证送达，开销最小
QoS 1	至少送达一次	保证送达，但可能重复
QoS 2	只送达一次	可靠性最高，开销最大

---

1. QoS 0：最多发送一次

QoS 0 表示消息发送一次，不进行确认。

特点是：

• 速度快；
• 开销小；
• 不保证消息一定送达。

适合一些允许少量丢失的数据，例如：

• 高频温度数据；
• 普通状态数据；
• 非关键监测数据。

例如，一个温度传感器每秒上传一次数据，即使偶尔丢一条，也不会严重影响整体趋势。

---

2. QoS 1：至少发送一次

QoS 1 表示消息至少送达一次。

特点是：

• 发送方会等待确认；
• 如果没有收到确认，可能会重发；
• 消息可能重复。

适合较重要的数据，例如：

• 告警信息；
• 设备状态变化；
• 关键运行数据。

因为 QoS 1 可能出现重复消息，所以平台端需要考虑去重逻辑。

---

3. QoS 2：只发送一次

QoS 2 表示消息只送达一次。

特点是：

• 可靠性最高；
• 流程最复杂；
• 通信开销最大。

适合非常关键、不能丢失也不能重复的消息，例如：

• 重要控制指令；
• 交易类消息；
• 严格状态同步场景。

不过在很多普通物联网项目中，QoS 0 和 QoS 1 使用更多，QoS 2 相对较少。

---

十一、Retain 保留消息是什么？

Retain Message，中文可以称为 保留消息。

当客户端发布消息时，如果设置了 Retain 标志，Broker 会保存这个 Topic 上的最后一条消息。

当新的客户端订阅该 Topic 时，Broker 会立即把这条保留消息发送给它。

---

1. Retain 的作用

例如，一个设备定期发布当前状态：

Topic: device/device001/status
Payload: {"status": "online"}
Retain: true

如果平台后来才订阅这个 Topic，仍然可以立即收到设备最近一次状态。

这对于状态类数据很有用。

例如：

• 设备在线状态；
• 灯的开关状态；
• 设备当前模式；
• 最新配置版本；
• 最近一次采集值。

---

2. Retain 使用注意事项

Retain 虽然方便，但也要谨慎使用。

如果保留消息内容已经过期，新的订阅者可能会收到旧数据，造成误判。

因此，建议：

• 状态类数据可以使用 Retain；
• 实时采集数据不一定需要 Retain；
• 控制命令通常不建议随意使用 Retain；
• Payload 中最好带时间戳，便于判断数据是否过期。

---

十二、Will Message 遗嘱消息是什么？

Will Message，也叫 遗嘱消息。

它的作用是：

当设备异常断开连接时，Broker 可以自动发布一条预设消息，通知其他客户端该设备掉线。

例如，设备连接 Broker 时设置遗嘱消息：

Will Topic: device/device001/status
Will Payload: {"status": "offline"}

如果设备正常断开连接，Broker 不会发送遗嘱消息。
如果设备因为断电、网络异常等原因突然断开，Broker 就会自动发布这条消息。

---

1. 遗嘱消息适合哪些场景？

遗嘱消息非常适合设备在线状态管理。

例如：

设备正常连接时发布：
Topic: device/device001/status
Payload: {"status": "online"}

设备异常断开时 Broker 自动发布：
Topic: device/device001/status
Payload: {"status": "offline"}

云平台订阅这个 Topic 后，就可以判断设备是否掉线。

---

2. 遗嘱消息的意义

在物联网系统中，设备是否在线是非常重要的信息。

通过遗嘱消息，可以实现：

• 设备离线提醒；
• 平台状态更新；
• 告警触发；
• 运维人员及时处理；
• 大屏实时显示设备在线率。

---

十三、Keep Alive 心跳机制是什么？

MQTT 使用 Keep Alive 机制来检测客户端是否仍然在线。

客户端连接 Broker 时，会设置一个 Keep Alive 时间。

如果在这个时间内客户端没有发送任何消息，就需要发送心跳包来告诉 Broker：

我还在线。

如果 Broker 在规定时间内没有收到客户端的消息或心跳，就会认为客户端已经断开连接。

---

1. 心跳机制的作用

Keep Alive 的主要作用包括：

• 检测设备是否在线；
• 及时发现断线；
• 保持连接活跃；
• 配合自动重连机制；
• 支持设备状态管理。

---

2. Keep Alive 设置建议

Keep Alive 时间不宜过短，也不宜过长。

如果设置太短：

• 心跳包太频繁；
• 增加网络流量；
• 增加设备功耗；
• 增加服务器压力。

如果设置太长：

• 设备掉线后发现不及时；
• 平台在线状态更新滞后。

实际项目中可以根据网络环境和业务要求设置，例如：

30 秒
60 秒
120 秒
300 秒

对于普通在线监测设备，60 秒或 120 秒是比较常见的选择。

---

十四、物联网设备如何通过 MQTT 连接云平台？

下面用一个简单流程说明设备如何通过 MQTT 连接云平台。

假设有一个温湿度设备，需要通过 MQTT 上传数据到云平台。

整体流程如下：

设备准备连接参数
        ↓
连接 MQTT Broker
        ↓
身份认证
        ↓
订阅下行命令 Topic
        ↓
发布设备状态
        ↓
定时上传传感器数据
        ↓
接收云平台控制命令
        ↓
断线后自动重连

---

1. 准备连接参数

设备连接 MQTT Broker 前，通常需要准备以下参数：

参数	说明
Broker 地址	MQTT 服务器地址，例如域名或 IP
端口	常见端口为 1883 或 8883
Client ID	客户端 ID，用于标识设备
Username	用户名
Password	密码
TLS/SSL	是否启用加密连接
Topic	发布和订阅的主题

例如：

Broker: mqtt.example.com
Port: 1883
Client ID: device001
Username: device001
Password: xxxxxx
Publish Topic: device/device001/data
Subscribe Topic: device/device001/command

如果使用加密连接，端口通常可能是：

8883

---

2. 设备连接 Broker

设备使用 MQTT 客户端程序连接 Broker。

连接时通常会携带：

• Client ID；
• Username；
• Password；
• Keep Alive；
• Clean Session；
• Will Message；
• TLS 证书信息。

连接成功后，Broker 会返回连接成功响应。

连接失败时，需要检查：

• Broker 地址是否正确；
• 端口是否开放；
• 用户名密码是否正确；
• Client ID 是否冲突；
• TLS 证书是否正确；
• 网络是否能访问服务器。

---

3. 设备订阅命令 Topic

设备连接成功后，通常会订阅一个平台下发命令的 Topic。

例如：

device/device001/command

平台如果想控制这个设备，就可以向这个 Topic 发布命令。

例如：

{
  "cmd": "set_interval",
  "value": 60
}

设备收到后，可以将采集周期设置为 60 秒。

---

4. 设备发布上线状态

设备连接成功后，可以发布一条上线消息。

例如：

Topic: device/device001/status
Payload: {"status": "online"}

如果配合 Retain 和 Will Message，就可以实现设备在线/离线状态管理。

例如：

设备上线：
{"status": "online"}

设备异常掉线：
{"status": "offline"}

---

5. 设备定时上传数据

设备采集到传感器数据后，可以定时发布到数据 Topic。

例如：

Topic: device/device001/data

Payload 示例：

{
  "device_id": "device001",
  "timestamp": 1714300000,
  "temperature": 28.5,
  "humidity": 65
}

云平台订阅该 Topic 后，可以进行：

• 数据解析；
• 数据存储；
• 曲线展示；
• 阈值判断；
• 告警推送；
• 报表统计。

---

6. 平台下发控制命令

平台可以向设备订阅的命令 Topic 发布控制指令。

例如：

Topic: device/device001/command

Payload 示例：

{
  "cmd": "reboot"
}

设备收到后执行重启操作。

再比如，平台下发修改采集周期命令：

{
  "cmd": "set_report_interval",
  "interval": 60
}

设备收到后，将数据上传周期调整为 60 秒。

---

7. 设备返回执行结果

为了让平台知道命令是否执行成功，设备通常需要返回命令响应。

例如：

Topic: device/device001/reply

Payload 示例：

{
  "cmd": "set_report_interval",
  "result": "success",
  "interval": 60
}

如果失败，可以返回：

{
  "cmd": "set_report_interval",
  "result": "failed",
  "reason": "invalid parameter"
}

这样平台就可以知道指令执行结果。

---

十五、一个完整 MQTT 通信示例

下面用一个简单例子串联整个流程。

假设设备编号为 device001。

1. Topic 设计

类型	Topic
数据上报	device/device001/data
状态上报	device/device001/status
命令下发	device/device001/command
命令回复	device/device001/reply

---

2. 设备上线

设备连接 Broker 后，发布上线状态：

Topic: device/device001/status
Payload: {"status": "online"}

---

3. 设备上传数据

设备上传温湿度数据：

Topic: device/device001/data
Payload: {"temperature": 28.5, "humidity": 65}

---

4. 平台下发命令

平台下发修改采集周期命令：

Topic: device/device001/command
Payload: {"cmd": "set_report_interval", "interval": 60}

---

5. 设备回复命令结果

设备执行成功后回复：

Topic: device/device001/reply
Payload: {"cmd": "set_report_interval", "result": "success"}

---

6. 设备异常离线

如果设备异常断开，Broker 自动发布遗嘱消息：

Topic: device/device001/status
Payload: {"status": "offline"}

通过这个流程，云平台就可以完成设备接入、数据采集、状态管理和远程控制。

---

十六、MQTT 和 HTTP 的简单对比

很多初学者会问：

MQTT 和 HTTP 都能上传数据，为什么物联网更常用 MQTT？

可以简单对比如下：

对比项	MQTT	HTTP
通信模式	发布/订阅	请求/响应
连接方式	通常长连接	通常短连接
实时性	较好	一般
通信开销	较小	较大
设备控制	更方便	需要轮询或额外机制
适合场景	设备上云、实时通信	API 接口、文件上传、系统对接
典型应用	IoT 平台、传感器、网关	Web 服务、业务系统、后台接口

简单理解：

MQTT 更像一个长期在线的消息通道；
HTTP 更像一次请求一次响应的接口调用。

所以，如果设备需要长期在线、实时上传数据、接收平台命令，MQTT 往往更合适。

如果只是偶尔上传数据、调用 API、上传文件或对接业务系统，HTTP 也很合适。

---

十七、MQTT 和 Modbus 的关系

在工业物联网中，MQTT 和 Modbus 经常一起出现。

但它们解决的问题不同。

• Modbus 常用于工业现场设备通信；
• MQTT 常用于设备或网关连接云平台。

例如：

PLC / 仪表 / 电表 → Modbus → 工业网关 → MQTT → 云平台

在这个架构中：

• PLC、电表、仪表通过 Modbus 与工业网关通信；
• 工业网关采集现场数据；
• 工业网关将数据转换成 JSON 或其他格式；
• 工业网关通过 MQTT 上传到云平台；
• 云平台进行存储、展示、告警和远程控制。

因此，Modbus 和 MQTT 通常不是替代关系，而是配合关系。

可以简单理解为：

Modbus 负责现场采集，MQTT 负责数据上云。

---

十八、MQTT 使用中的常见问题

1. Client ID 冲突

MQTT 中，Client ID 通常需要唯一。

如果两个设备使用相同的 Client ID 连接同一个 Broker，可能会导致其中一个设备被踢下线。

因此，每台设备应该使用唯一的 Client ID。

例如：

device001
device002
device003

或者：

gateway_SN123456

---

2. Topic 设计混乱

如果 Topic 设计不清晰，后期系统会很难维护。

例如，不建议随意设计成：

data1
test
device
abc

更建议使用层级清晰的方式：

factory/line01/device001/data
factory/line01/device001/status
factory/line01/device001/command

---

3. 忘记处理断线重连

现场设备网络不稳定是常见情况。

因此 MQTT 客户端需要考虑：

• 连接失败重试；
• 断线自动重连；
• 重连后重新订阅 Topic；
• 离线期间数据是否缓存；
• 重复消息如何处理。

---

4. 没有做安全认证

如果 MQTT Broker 暴露在公网，必须考虑安全问题。

建议至少使用：

• 用户名和密码；
• TLS/SSL 加密；
• 访问控制 ACL；
• 设备级权限管理；
• 不同设备使用不同账号；
• 禁止匿名访问。

---

5. QoS 设置不合理

QoS 并不是越高越好。

QoS 越高，可靠性越高，但通信开销也越大。

一般建议：

• 普通采集数据：QoS 0 或 QoS 1；
• 告警数据：QoS 1；
• 重要控制命令：QoS 1 或 QoS 2；
• 高频非关键数据：QoS 0。

---

十九、MQTT 安全性建议

物联网设备数量多，一旦安全设计不当，可能带来较大风险。

因此，在实际项目中，MQTT 安全非常重要。

建议从以下几个方面考虑。

1. 使用用户名和密码

不要让设备匿名连接 Broker。

每台设备最好使用独立账号，方便权限管理和问题追踪。

---

2. 使用 TLS/SSL 加密

如果设备通过公网连接云平台，建议使用 TLS/SSL 加密。

普通 MQTT 端口通常是：

1883

MQTT over TLS 常见端口是：

8883

加密连接可以防止数据在传输过程中被窃听或篡改。

---

3. 限制 Topic 权限

不同设备应该只能访问自己的 Topic。

例如，设备 device001 只能发布或订阅：

device/device001/#

不能访问：

device/device002/#

这样可以防止设备之间互相读取或控制。

---

4. 避免敏感信息放在 Topic 中

Topic 有时可能会被日志记录或监控系统显示，因此不建议在 Topic 中放入密码、Token 等敏感信息。

例如，不建议：

device/device001/password123/data

---

5. 定期更新认证信息

对于长期运行的物联网系统，建议支持：

• 密码更新；
• Token 更新；
• 证书更新；
• 设备吊销；
• 权限变更。

这样可以提高系统安全性。

---

二十、MQTT 适合哪些应用场景？

MQTT 的应用非常广泛。

常见场景包括：

1. 智能家居

例如：

• 智能灯；
• 智能插座；
• 温湿度传感器；
• 空调控制；
• 门锁状态上报。

home/livingroom/light/status
home/livingroom/light/control

---

2. 工业物联网

例如：

• 工业网关上传 PLC 数据；
• 电表数据采集；
• 设备运行状态监测；
• 远程告警；
• 工厂能耗监测。

factory/line01/plc001/data
factory/line01/gateway001/status

---

3. 车联网

例如：

• GPS 位置上传；
• 车辆速度上传；
• 发动机状态；
• 车辆告警；
• 远程诊断。

vehicle/truck001/gps
vehicle/truck001/alarm

---

4. 智慧农业

例如：

• 土壤湿度监测；
• 温室环境监测；
• 自动灌溉控制；
• 水泵远程控制；
• 光照强度采集。

farm/greenhouse01/temperature
farm/greenhouse01/pump/control

---

5. 能源与电力

例如：

• 光伏逆变器数据上传；
• 储能系统监控；
• 电表数据采集；
• 配电柜状态监测；
• 远程告警。

energy/site001/meter001/data
energy/site001/inverter001/status

---

二十一、简单总结 MQTT 的核心概念

为了方便记忆，可以把 MQTT 的核心概念总结如下：

概念	简单理解
Client	连接 MQTT 的客户端，可以是设备或平台
Broker	MQTT 消息服务器，负责转发消息
Topic	消息主题，类似消息地址
Payload	消息内容
Publish	发布消息
Subscribe	订阅消息
QoS	消息可靠性等级
Retain	保留最后一条消息
Will Message	异常掉线时自动发送的遗嘱消息
Keep Alive	心跳机制，用于检测连接状态

如果只记住一句话：

MQTT 是一种基于发布/订阅模式的轻量级消息协议，非常适合物联网设备上云、数据采集和远程控制。

---

二十二、总结

MQTT 是物联网系统中非常重要的通信协议。

它具有轻量级、低开销、支持长连接、支持发布/订阅、适合不稳定网络、支持双向通信等特点，因此被广泛用于设备上云、工业网关、智能家居、车联网、能源监测等场景。

在 MQTT 系统中，最核心的三个概念是：

• Client：客户端，可以是设备、网关、平台或应用；
• Broker：消息服务器，负责接收和转发消息；
• Topic：主题，用于区分不同类型的消息。

一个典型的设备通过 MQTT 连接云平台的流程是：

设备连接 Broker
    ↓
设备认证成功
    ↓
设备订阅命令 Topic
    ↓
设备发布在线状态
    ↓
设备定时上传数据
    ↓
平台下发控制命令
    ↓
设备执行并回复结果

在工业物联网中，MQTT 通常和 Modbus、工业网关一起使用：

PLC / 仪表 / 电表 → Modbus → 工业网关 → MQTT → 云平台

可以简单理解为：

Modbus 负责现场数据采集，MQTT 负责数据上传云平台。

掌握 MQTT 的基本原理后，就能更好地理解物联网设备如何接入云平台，以及设备数据如何实现远程采集、监控和控制。

---

下一篇预告

在下一篇文章中，我们可以继续深入介绍：

《什么是 Modbus？工业网关如何采集 PLC 和仪表数据》

下一篇将重点讲解：

• Modbus 是什么；
• Modbus RTU 和 Modbus TCP 的区别；
• 主站 Master 和从站 Slave 的关系；
• 寄存器、线圈、功能码是什么意思；
• 工业网关如何通过 Modbus 采集现场设备数据。