📚 课程目录第3章 MQTT Broker选型与部署

3. MQTT Broker选型与部署

核心原理：Broker 在 MQTT 架构中的角色与选型维度

在 MQTT 物联网远程控制体系中，Broker（消息代理）是所有消息流转的中枢节点。设备端（Publisher/Subscriber）并不直接通信，而是统一连接到 Broker，由 Broker 负责主题（Topic）匹配、消息路由、会话状态维护与 QoS 级别保障。因此，Broker 的稳定性、并发能力与功能特性直接决定了整个远程控制系统的可靠性。

选型时需重点评估以下维度：

并发连接数：家用场景可能仅需数百连接，工业网关则需支撑数万乃至数十万设备长连接。
QoS 与持久化：是否完整支持 QoS 0/1/2，是否支持消息持久化到磁盘，防止 Broker 重启后消息丢失。
安全机制：是否支持 TLS/SSL 加密、用户名密码认证、客户端证书认证（双向 TLS）。
集群与扩展性：单机版是否够用，还是需要多节点集群实现负载均衡与高可用。
资源占用与部署环境：Mosquitto 极轻量，适合树莓派、路由器等嵌入式设备；EMQX 功能丰富，适合云服务器或边缘网关。
可观测性：是否提供监控接口、日志系统或 Dashboard 界面，便于排障。

选型建议：若项目为家庭智能家居或小型实验室原型，Mosquitto 足够；若面向商业产品、需管理大量设备且要求可视化管理与规则引擎，优先考虑 EMQX。

方法流程：Mosquitto 与 EMQX 的安装部署步骤

方案一：Mosquitto —— 轻量级 Broker 部署

Mosquitto 采用 C 语言实现，二进制体积小、内存占用低，非常适合树莓派、OpenWrt 路由器或低配云主机。以下以 Ubuntu 22.04 为例展示安装与基础配置流程。

# 1. 安装 Mosquitto 及客户端工具
sudo apt update
sudo apt install -y mosquitto mosquitto-clients

# 2. 查看服务状态（默认监听 1883 端口）
systemctl status mosquitto

# 3. 编辑配置文件（默认路径 /etc/mosquitto/mosquitto.conf）
sudo nano /etc/mosquitto/mosquitto.conf

基础配置示例（允许匿名访问仅限内网测试环境）：

# /etc/mosquitto/mosquitto.conf
persistence true
persistence_location /var/lib/mosquitto/

# 监听端口
listener 1883
protocol mqtt

# 日志
log_dest file /var/log/mosquitto/mosquitto.log

# 安全配置（生产环境务必开启）
allow_anonymous false
password_file /etc/mosquitto/passwd

创建用户密码并重启服务：

sudo mosquitto_passwd -c /etc/mosquitto/passwd iot_user
sudo systemctl restart mosquitto

# 测试发布与订阅（终端 A 订阅，终端 B 发布）
mosquitto_sub -h localhost -t test/topic -u iot_user -P 密码
mosquitto_pub -h localhost -t test/topic -m "hello" -u iot_user -P 密码

方案二：EMQX —— 企业级 Broker 部署

EMQX 基于 Erlang/OTP 开发，原生支持分布式集群、规则引擎与 Dashboard 可视化管理。适合需要处理大量设备连接、进行消息流转与数据桥接的生产级项目。

# 1. 使用 Docker 快速部署（推荐）
docker run -d --name emqx \
  -p 1883:1883 -p 8083:8083 -p 8084:8084 \
  -p 18083:18083 \
  emqx/emqx:5.8.0

# 2. 访问 Dashboard（默认账号 admin / public）
# 浏览器打开 http://<服务器IP>:18083

# 3. 查看日志
docker logs -f emqx

EMQX 的 Dashboard 提供可视化的连接管理、主题监控与规则配置界面。在“认证鉴权”菜单中可配置用户名密码数据库，在“规则引擎”中可将 MQTT 消息直接转发至 HTTP 服务或 Kafka。

  部署验证清单：
  使用 netstat -tlnp | grep 1883 确认端口监听正常。
从外部设备测试连接时，检查云安全组是否放行 1883（MQTT）与 8883（MQTT over TLS）端口。
通过 mosquitto_pub 与 mosquitto_sub 完成一次端到端消息收发测试。
查看 Broker 日志确认无认证失败或异常断连记录。

案例场景：智能家居远程控制中的 Broker 选型对比

假设我们正在开发一套智能家居远程控制系统，包含 50 个 WiFi 智能插座、20 个温湿度传感器和 10 个红外遥控器，同时需要手机 App 远程查看状态并下发控制指令。下表对比了两种 Broker 在该场景下的适用性：

对比维度	Mosquitto	EMQX
内存占用	约 5~15 MB	约 200~500 MB
最大连接数	数千级（单机）	百万级（集群）
Dashboard 可视化管理	无（需第三方工具）	内置 Web Dashboard
规则引擎 / 数据桥接	需额外开发	内置 SQL 规则引擎
部署硬件要求	树莓派 / 低配 VPS 即可	建议 2 核 4G 以上
适用阶段	原型验证 / 小型项目	商业产品 / 大规模部署

在本案例中，若采用 Mosquitto 部署在树莓派上，需额外编写 Web 后端程序订阅设备主题并存储数据；若采用 EMQX，则可通过规则引擎直接将温湿度数据写入时序数据库，并将手机 App 的控制指令通过 HTTP 桥接转发至设备端，显著减少开发工作量。

误区与复盘：Broker 部署中的常见问题

误区一：忽略 QoS 与消息持久化的实际效果
许多开发者将 QoS 2 视为“绝对不丢消息”，但 QoS 2 只能保证端到端传输过程中不丢失，若 Broker 未开启持久化（persistence），重启后内存中的消息仍会丢失。对于关键控制指令，应同时启用 Broker 持久化并在设备端设计消息确认重发机制。

误区二：开放匿名访问导致安全隐患
在公网部署 Broker 时若保留 allow_anonymous true，扫描工具可在数分钟内发现并滥用你的 Broker。复盘教训：生产环境必须关闭匿名访问，并启用 TLS 加密。至少使用用户名密码认证，重要项目建议双向 TLS 证书认证。

复盘总结：Broker 选型不是越强大越好，而是匹配实际设备规模与团队维护能力。Mosquitto 胜在轻量简单，EMQX 胜在功能全面。部署后务必进行安全加固、连接压力测试与日志监控，才能保障远程控制系统的长期稳定运行。