MQTT、EMQX、Broker 相关技术和协议是物联网最常见的技术，在本篇文章中我们会对这三点进行介绍。一句话简述：EMQX 是一款基于 MQTT 协议的工业级 Broker 产品。MQTT：设备与 Broker 通信的「语言」（轻量级物联网协议）；Broker：设备通信的「消息枢纽」（接收、路由、转发消息的中间件角色）；EMQX：实现 Broker 角色的「具体软件」（高性能、分布式，专为物联网场景设计）。
三者的协作逻辑：
设备（MQTT Client）用 MQTT 协议「说话」，通过网络连接到 EMQX（Broker），由 EMQX 负责把设备的消息精准转发给其他设备------EMQX 是 MQTT 协议的「最佳载体」，MQTT 是 EMQX 的「核心通信方式」。
除了EMQX这一种Broker之外，还存在多种其他类型的Broker。
- Mosquitto：轻量级、资源占用低，适合小型项目/测试；
- RabbitMQ：支持多协议（AMQP/MQTT），适合混合消息场景；
- AWS IoT Core/Azure IoT Hub：云厂商托管的 Broker，无需自建服务器。
EMQX 的优势是「工业级性能」和「物联网场景适配」，适合大规模、高可用需求。
1. 各组件核心职责拆解
| 组件 | 本质定位 | 核心作用 | 关键特性/注意点 |
|---|---|---|---|
| MQTT | 通信协议（设备间的「语言」） | 定义设备与 Broker 之间的消息格式、交互流程 | 轻量级（协议头最小2字节）、支持 QoS 0/1/2、发布/订阅模式 |
| Broker | 消息中间件（「消息枢纽」） | 1. 管理设备连接；2. 验证设备权限；3. 路由消息；4. 保障消息可靠传输 | 是 MQTT 通信的核心，没有 Broker 设备无法解耦通信 |
| EMQX | 工业级 MQTT Broker 产品 | 实现 Broker 所有核心功能，且优化大规模、高可靠场景 | 支持百万级设备连接、分布式集群、多协议兼容（MQTT/CoAP/HTTP等） |
2. 连接与权限：两层独立控制
- 网络层：防火墙放行 EMQX 的 MQTT 端口（如 1883 未加密、8883 加密），设备才能与 EMQX 建立连接；
- 业务层：连接后能否「订阅（Subscribe）」「发布（Publish）」，由 EMQX 的 ACL 权限规则控制（二者可分离，如「仅允许发布数据，禁止订阅」）。
| 控制层面 | 作用范围 | 核心目的 | 例子（EMQX 配置） |
|---|---|---|---|
| 网络层（端口） | 能否与 Broker 建立连接 | 阻止非法 IP 接入网络（第一道防线） | 防火墙放行 1883（MQTT 端口），允许设备 IP 连接 |
| 业务层（权限） | 连接后能否订阅/发布 | 控制设备能操作的主题（第二道防线） | 仅允许设备订阅 sensor/temp，禁止发布任何主题 |
只有两道关都通过，设备才能完成对应操作：
- 网络层不通（端口未放行）：设备连不上 Broker，订阅/发布都做不了；
- 网络层通但业务层无权限：设备能建立连接（CONNACK 成功），但订阅时返回「权限拒绝」（SUBACK 中返回失败码），发布时消息被 Broker 丢弃/返回错误（PUBACK 失败）。
3. 为什么「能订阅≠能发布」？
MQTT Broker 的权限控制是「细粒度、分操作」的------可以精确配置：
- 允许某设备「仅订阅」特定主题（如传感器只能订阅「控制指令」主题，不能发布数据）；
- 允许某设备「仅发布」特定主题（如传感器只能上报数据到
sensor/temp，不能订阅其他主题）； - 允许某设备「既订阅又发布」部分主题（如网关既能上报设备状态，又能订阅云平台指令）；
- 禁止某设备「订阅和发布」所有主题（仅允许连接，无任何业务操作权限）。
4. 总结
- IP 开通端口访问，只是给设备「进门的资格」（能连接 Broker）；
- 订阅和发布是「进门后的操作权限」，由 Broker 的 ACL、数据库权限等规则独立控制；
- 「能订阅」和「能发布」没有必然关联，生产环境中更推荐「最小权限原则」：例如传感器仅允许发布数据主题，控制端仅允许订阅指令主题，避免权限滥用。