1. 课程导入
1.1 MQTT协议核心原理：一条消息的旅程
MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是一种基于发布/订阅（Pub/Sub）模式的轻量级消息协议，由IBM于1999年提出，2014年成为OASIS标准。它的设计哲学是“极简、低带宽、高容忍”，专为网络不稳定、设备资源受限的物联网场景而生。
理解MQTT，必须抓住三个核心角色与一条消息的完整生命周期：
- Broker（代理服务器）：消息的中枢，负责接收所有发布者的消息，并根据主题（Topic）将消息路由给所有匹配的订阅者。Broker是集群部署的核心对象。
- Publisher（发布者）：数据产生方，例如温度传感器、智能电表。它只负责向Broker发送消息，不关心谁在消费。
- Subscriber（订阅者）：数据消费方，例如监控大屏、手机App。它向Broker表达“我对某个主题感兴趣”，之后Broker会持续推送相关消息。
消息本身通过主题（Topic）进行路由，主题采用层级结构，例如 factory/zone1/temperature。订阅者可以使用通配符 +（单层）和 #（多层）实现灵活匹配，例如订阅 factory/+/temperature 可接收所有车间的温度数据。
核心机制——QoS（服务质量）等级：MQTT提供三种消息投递保障，这是它与HTTP等协议最大的区别之一。
- QoS 0（至多一次）：消息可能丢失，适用于环境温度等周期性上报数据。
- QoS 1（至少一次）：消息保证送达，但可能重复，适用于告警通知。
- QoS 2（恰好一次）：消息不重不漏，适用于计费、指令下发等关键场景。
下图展示了MQTT协议中一条消息从传感器到多个订阅端的完整流转路径，以及QoS等级在其中的作用位置：
1.2 物联网场景需求：为什么HTTP不够用？
在典型的物联网系统中，设备数量动辄数千甚至数十万，网络环境复杂多变。如果直接使用HTTP协议，会面临以下难以逾越的障碍：
| 对比维度 | HTTP/1.1 | MQTT | 物联网场景痛点 |
|---|---|---|---|
| 通信模式 | 请求-响应（同步） | 发布-订阅（异步） | 传感器数据需要主动推送，而非被动等待查询 |
| 报文开销 | 头部数百字节 | 最小仅2字节固定头 | NB-IoT等窄带网络流量极其宝贵 |
| 连接管理 | 短连接为主 | 长连接+心跳保活 | 设备频繁重连会耗尽基站资源 |
| 离线消息 | 不支持 | 持久会话+离线消息 | 设备休眠后需要补收错过的指令 |
| 实时性 | 轮询延迟高 | 毫秒级推送 | 告警事件需要秒级响应 |
以智能工厂为例，一条产线上可能部署200+传感器，每秒钟产生多组数据。若采用HTTP轮询，每个传感器每5秒请求一次，网关需要维护大量无意义的TCP连接；而MQTT长连接只需一次握手，后续所有数据都通过同一个连接双向流动，大幅降低网络开销和延迟。
1.3 集群部署的必要性：单点Broker的致命局限
当业务规模从几十台设备扩展到数万台设备时，单节点MQTT Broker会暴露出一系列问题。集群部署不是“锦上添花”，而是物联网平台走向生产环境的必由之路。
单点故障（SPOF）风险：如果Broker宕机，所有设备将同时失去连接，生产数据全部中断。在工业场景中，这可能导致产线停机、数据丢失，甚至安全事故。集群通过多节点冗余，将可用性从99.9%提升至99.99%以上。
集群部署需要解决三大核心问题：
- 连接负载均衡：数万设备不可能全部连到同一个Broker上，需要负载均衡器（如HAProxy、Nginx）将设备连接分散到多个Broker节点。
- 消息共享路由：设备A连在节点1上，设备B连在节点2上，A发布的消息必须能被B订阅到。这要求集群内部实现主题树同步或消息转发。
- 会话状态迁移：当某个节点宕机时，原本连接在该节点上的设备需要被重连到其他节点，且其订阅关系、离线消息不能丢失。
当前主流的MQTT集群方案包括：
- EMQX：基于Erlang/OTP，天生支持分布式集群，节点间自动发现与数据同步。
- Mosquitto：轻量级，但原生不支持集群，需借助外部桥接或共享订阅插件。
- VerneMQ：同样基于Erlang，强调高可用与水平扩展。
- HiveMQ：商业级方案，提供完善的集群管理与监控。
学习路径建议：本课程将围绕EMQX展开，因为它提供了最完整的集群功能（节点发现、会话接管、共享订阅、规则引擎），且社区活跃、文档丰富。后续章节会从单机部署开始，逐步过渡到多节点集群、负载均衡、安全加固与运维监控。
1.4 常见误区与复盘
在开始集群部署之前，先厘清几个容易混淆的概念，避免后续踩坑：
误区一：集群 = 多开几个Broker进程？
如果只是启动多个独立的Mosquitto实例，它们之间互不通信，设备A发布的消息设备B依然收不到。真正的集群必须实现消息路由共享，即每个节点都知道其他节点上的订阅关系。
如果只是启动多个独立的Mosquitto实例，它们之间互不通信，设备A发布的消息设备B依然收不到。真正的集群必须实现消息路由共享，即每个节点都知道其他节点上的订阅关系。
误区二：负载均衡器就是集群的全部？
负载均衡只解决了“连接分发”问题，但节点间的数据同步、脑裂处理、消息去重才是集群的核心难点。没有内部通信机制的“集群”只是伪集群。
负载均衡只解决了“连接分发”问题，但节点间的数据同步、脑裂处理、消息去重才是集群的核心难点。没有内部通信机制的“集群”只是伪集群。
误区三：QoS 2 在集群中一定可靠？
跨节点的QoS 2需要分布式事务保证，实现复杂度极高。部分集群方案会降级处理，或依赖底层存储（如Redis、RocksDB）来保证最终一致性。生产环境中需根据业务容忍度选择合适的QoS等级。
跨节点的QoS 2需要分布式事务保证，实现复杂度极高。部分集群方案会降级处理，或依赖底层存储（如Redis、RocksDB）来保证最终一致性。生产环境中需根据业务容忍度选择合适的QoS等级。