物联网MQTT - 技术栈

MQTT应用层通信协议

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输） ，是一种轻量级、基于发布 / 订阅 (Pub/Sub) 模式的应用层通信协议，专为低带宽、不稳定网络、资源受限设备（物联网 IoT）设计。通用消息传输协议（Pub/Sub），国际标准。

名字里带 Queue，但不是消息队列，没有消息持久缓存、消息排队的概念，只是协议名称

MQTT 3.1.1：物联网最广泛使用，简单够用，绝大多数终端 SDK 支持

MQTT 5.0（推荐新项目） 新增：会话过期、消息载荷格式、原因码、共享订阅、用户属性、流量控制、更大报文长度，功能更强，复杂度略高

载荷内容完全不限制，可以是 JSON、文本、二进制

典型使用场景

✅物联网：传感器、充电桩、电表、车载终端、智能设备上报数据

✅移动推送：低功耗消息推送

✅工业物联网、边缘网关、设备远程控制

❌不适合：大量大文件传输、复杂事务消息（改用 Kafka/RabbitMQ）

核心模型：发布 / 订阅 Pub/Sub

角色分为 3 种

Broker（消息服务器 / 代理）：中间枢纽，接收消息、转发给订阅者，常见：EMQX、Mosquitto、VerneMQ
Publisher（发布者） ：向 Broker 发送消息，不关心谁接收，如环卫车辆、GPS 终端、温湿度传感器，定时上报位置 / 传感器数据 → Publisher
Subscriber（订阅者）：向 Broker 订阅主题，只收到自己订阅的消息

常用的Broker

Mosquitto：轻量小巧，适合测试、小型部署
EMQX：高性能集群，百万级连接，工业 / 项目最常用
VerneMQ：高可用集群
AWS IoT、阿里云 IoT、腾讯云 IoT（云托管 MQTT 服务）

EMQX

EMQX 是基于 Erlang 开发的分布式高性能 MQTT Broker（物联网消息服务器），是目前工业 / 车联网 / 环卫 IoT 最主流的 MQTT 服务，完整支持 MQTT3.1.1 / MQTT5.0、MQTT‑WebSocket、QUIC，自带 Web 管理面板、认证授权、规则引擎、数据桥接、集群能力EMQX。

EMQX：软件产品，完整实现 MQTT3.1.1 / MQTT5.0 协议，作为 Broker 运行，负责接收、路由、转发 MQTT 消息。

EMQX 开源社区版（Open Source） 免费，单机、小规模集群；5.x 采用 Core‑Replicant 架构，适合中小项目，集群节点数量有限制assets.emq...
EMQX 企业版（Enterprise） 商业授权，大规模集群、跨地域部署、高级数据集成、技术支持，单集群可支撑上亿并发连接EMQX
EMQX Edge：边缘网关轻量版本，资源受限本地边缘端
EMQX Cloud：托管云服务，不用自己部署运维

二、EMQX5 核心架构（重点）

EMQX5 引入 Core + Replicant（核心节点 + 副本节点） 分离架构，解决 4.x 全互联集群瓶颈GitHub

Core 节点：保存会话、订阅、认证、集群元数据，负责状态持久化（RocksDB）
Replicant 副本节点 ：只做消息转发、接收设备连接，不存储会话数据，横向扩容只增加 Replicant 即可，极大提升集群规模
无主集群，节点对等，自动发现，支持滚动升级，避免单点故障

三、核心功能

1. 协议接入

MQTT 3.1.1 / MQTT5.0，完整支持遗嘱 LWT、Retain 保留消息、共享订阅、会话过期、用户属性
MQTT over WebSocket（前端网页直接连接）、QUIC、CoAP、LwM2M
常用端口 EMQX
- 1883：明文 MQTT TCP（内网测试）
- 8883：MQTTS TLS 加密（生产必用）
- 8083：WebSocket MQTT
- 8084：WSS 加密 WebSocket
- 18083：Dashboard 管理后台（默认账号 admin/public）

2. 认证与鉴权（安全控制）

支持多链认证，可组合多种方式：

内置数据库（本地账号）
MySQL / PostgreSQL / Redis / JWT 令牌
HTTP 外部 API 认证（对接自有用户系统） 鉴权（ACL）：控制客户端只能发布 / 订阅指定 topic，防止越权，平台级设备权限隔离必备

3. 规则引擎 + 数据桥接（EMQX 最大亮点）

无需开发中间转发服务，在 Broker 内部直接处理消息并转发到下游

Rule SQL：筛选 topic、提取 payload 字段、转换数据
数据桥接（Bridge）：转发到 MySQL、Postgres、Redis、Kafka、RabbitMQ、HTTP WebHook、另一个远端 MQTT Broker

典型场景：车辆上报位置→EMQX 规则过滤→直接写入数据库 / 推送到 Kafka，省去独立消息转发服务

4. 共享订阅（MQTT5 重要特性）

格式：$share/group1/sensor/temp 多条业务客户端组成消费组，同一条消息只分给组内一个客户端，实现负载均衡，适合多实例后端服务消费设备数据（车载平台、环卫平台大量使用）

5. 消息持久化、离线消息

依赖 RocksDB 持久化存储会话与离线消息生效全部条件：

ClientID 固定
MQTT5 CleanStart=false（3.1.1 CleanSession=false）
QoS1/QoS2
EMQX 开启消息队列持久化并配置队列上限

坑：CleanStart=true 时，断开立即销毁会话，离线消息全部丢失，很多人踩坑EMQX

6. 桥接（MQTT Bridge）

EMQX ↔ 远端 MQTT 服务器双向同步 topic，实现边缘 EMQX 和云端 EMQX 数据互通，边缘云协同架构常用

四、快速部署（Docker，最常用）

复制代码

docker run -d \
  --name emqx5 \
  --restart unless-stopped \
  -p 1883:1883 \
  -p 8883:8883 \
  -p 8083:8083 \
  -p 8084:8084 \
  -p 18083:18083 \
  -v /opt/emqx/data:/opt/emqx/data \
  -v /opt/emqx/log:/opt/emqx/log \
  emqx/emqx:5.8

启动后浏览器访问 http://IP:18083，默认账号 admin /public，上线第一件事修改密码，关闭匿名连接

五、EMQX 典型生产坑点（物联网 / 车联网高频问题）

匿名连接默认开启，上线务必关闭，配置认证，否则任何人可接入
Retain 保留消息不会自动清理，大量堆积占用内存，需要配置数量上限、定时清理
离线消息有队列上限（默认 1000 条），设备长时间离线后消息溢出丢弃，不是无限缓存
QoS1 会重复投递消息，业务代码必须自行去重，EMQX 不做应用层去重
4.x 集群节点过多同步风暴；新项目必须 5.x Core+Replicant 架构扩容
单条消息上限约 1MB，不适合传输大文件，大文件拆分或改用 HTTP
心跳时间（KeepAlive）设置过长，网络闪断无法及时感知离线，遗嘱消息延迟触发
共享订阅只在同一个消费组内负载均衡，普通订阅仍然是消息广播给全部订阅者

六、适用场景 & 不适合场景

✅适合：车载终端、环卫设备、充电桩、工业传感器、智能硬件实时上报、远程指令下发、边缘 - 云端消息同步、百万设备长连接 ❌不适合：海量大文件传输、复杂事务消息、日志流式分析（日志场景直接 Kafka）

七、EMQX 与其他 Broker 横向对比

EMQX：长连接百万级、MQTT5、集群、规则引擎、数据桥接、Dashboard；物联网设备接入首选
Mosquitto：轻量简单，资源占用低；适合测试、几十台小规模设备，缺少企业级集群与数据集成
VerneMQ：分布式集群强，但是生态、可视化、规则引擎弱于 EMQX
Kafka ：流式日志持久化，不擅长海量长连接，不替代 MQTT Broker；常和 EMQX 搭配使用，EMQX 接入设备→桥接 Kafka 做大数据分析