3. MQTT Broker选型与部署

MQTT Broker（消息代理）是设备闭环告警系统的中枢神经，所有设备状态上报、告警规则触发、通知下发都经由Broker进行路由。选型失误会导致连接数瓶颈、消息延迟飙升或安全漏洞；部署不当则会造成单点故障或性能浪费。本章将从Broker核心能力对比、单机与集群部署策略、安全加固三个维度展开，并结合一个实际的工厂设备告警项目进行全流程拆解。

上图展示了从需求输入到安全加固的完整决策链路。在实际项目中，选型不是一步到位的，需要根据设备规模、网络环境、团队运维能力反复权衡。下面逐一展开。

3.1 常见Broker对比：EMQX、Mosquitto、VerneMQ

3.1.1 核心原理与能力差异

MQTT Broker本质是一个消息路由器，负责接收客户端发布的Topic消息，并根据订阅关系将消息推送给订阅者。不同Broker的差异主要体现在：并发连接数、消息吞吐量、协议扩展（如MQTT 5.0、WebSocket）、集群能力、规则引擎、数据持久化等方面。

• Mosquitto：Eclipse基金会开源，C语言实现，极轻量（内存占用约5-10MB），适合边缘网关、嵌入式设备、中小规模场景。支持MQTT 3.1/3.1.1/5.0，但集群能力弱（需借助第三方如mosquitto-go-auth），无内置规则引擎。
• EMQX：Erlang/OTP编写，分布式架构，单机可支撑百万级连接，内置规则引擎、数据桥接（Kafka、数据库）、热配置、Dashboard监控。支持MQTT 5.0、WebSocket、CoAP等。集群扩展简单，适合工业物联网、车联网、智慧城市等大规模场景。
• VerneMQ：同样是Erlang实现，强调高可用和集群一致性，但社区活跃度低于EMQX，插件生态相对较少，适合对集群一致性有特殊要求的场景。

3.1.2 判断方法：如何根据项目需求选型

选型不能只看宣传参数，要结合设备在线率、消息QoS等级、网络稳定性、运维团队技术栈综合判断。以下是一个实用的决策清单：

1. 连接规模：如果设备数小于1万，且未来3年不会超过5万，Mosquitto足够；如果设备数在10万以上，或需要弹性扩展，直接选EMQX。
2. 消息吞吐量：用JMeter或emqtt-bench压测工具模拟真实场景，观察Broker在QoS1下的TPS和P99延迟。Mosquitto在单核CPU下约能处理2-3万TPS，EMQX在相同硬件下可达10万+。
3. 功能需求：是否需要消息持久化、离线消息、遗嘱消息、共享订阅？是否需要将消息直接写入数据库或Kafka？EMQX的规则引擎可以免去额外开发。
4. 运维成本：Mosquitto配置简单，但监控和告警需要自己搭建；EMQX自带Dashboard和Prometheus指标接口，但需要学习Erlang/OTP的集群管理。

3.1.3 案例拆解：某工厂设备告警系统的Broker选型

背景与约束：某汽车零部件工厂需要接入3000台PLC设备，每台设备每5秒上报一次运行状态（温度、振动、电流），同时有200个工位显示屏订阅告警消息。网络环境为工厂内网，带宽有限，IT团队只有2人，且不熟悉Erlang。

初始目标：保证告警消息端到端延迟小于500ms，Broker宕机后5分钟内恢复。

分析过程：3000台设备，每5秒上报一次，TPS约为600（3000/5），加上告警消息，峰值TPS约1000。这个规模Mosquitto完全能扛住。但考虑到工厂未来会新增设备到1万台，且需要将告警消息写入MySQL用于追溯，如果选Mosquitto，需要额外开发消息转发服务；而EMQX的规则引擎可以直接将消息写入MySQL。

实际操作：最终选择EMQX单机部署（4核8GB），配置规则引擎将告警Topic（/factory/alarm）写入MySQL，同时通过WebSocket推送给工位显示屏。部署后实测：TPS峰值1200时，P99延迟80ms，满足要求。

结果与复盘：如果当初选Mosquitto，虽然初期成本低，但后续需要开发消息转发服务，且集群扩展困难。EMQX虽然占用资源多（约500MB内存），但功能集成度高，减少了开发工作量。经验是：选型要着眼未来3年的设备增长，而不是只看当前规模。

3.2 单机与集群部署：从“能跑”到“高可用”

3.2.1 单机部署要点

单机部署适合设备数小于5万、允许短时停机维护的场景。关键配置项包括：

• 监听器：默认1883端口（明文），如需TLS则配置8883端口。
• 系统资源限制：Linux下需要调整文件描述符上限（ulimit -n 65535），否则连接数超过默认值会报错。
• 持久化：EMQX默认将消息存储在内存中，如果开启持久化（如使用内置数据库），需要配置存储路径和定期备份。
• 日志：设置日志轮转，避免磁盘写满。

# EMQX 单机部署示例（docker-compose.yml）
version: '3'
services:
  emqx:
    image: emqx/emqx:5.0.26
    container_name: emqx
    ports:
      - "1883:1883"   # MQTT
      - "8883:8883"   # MQTT/SSL
      - "8083:8083"   # WebSocket
      - "18083:18083" # Dashboard
    environment:
      - EMQX_NODE_NAME=emqx@127.0.0.1
      - EMQX_LISTENER__TCP__EXTERNAL__MAX_CONNECTIONS=100000
    volumes:
      - emqx-data:/opt/emqx/data
      - emqx-log:/opt/emqx/log
volumes:
  emqx-data:
  emqx-log:

3.2.2 集群部署：节点发现与负载均衡

当设备数超过单机承载能力，或需要高可用（Broker宕机不影响业务）时，必须采用集群。EMQX集群基于Erlang分布式协议，节点之间自动同步订阅关系和路由表。部署要点：

1. 节点发现：使用静态节点列表或DNS发现（如Kubernetes中的Headless Service）。
2. 负载均衡：客户端连接需要经过负载均衡器（如Nginx、HAProxy）分发到不同节点，同时开启MQTT的负载均衡算法（如一致性哈希）保证同一客户端的会话固定在同一节点。
3. 共享订阅：当多个订阅者订阅同一Topic时，使用共享订阅（$share/group/topic）实现消息负载均衡，避免单点消费压力。
4. 脑裂问题：集群节点之间网络分区时，需要配置quorum（多数派）机制，避免出现双主写入。

3.2.3 案例拆解：从单机到集群的平滑演进

背景：某智慧园区项目初期接入5000个传感器，使用单机EMQX。半年后设备增至3万，且客户要求Broker故障时业务不中断。

关键指标：单机CPU使用率从30%升至85%，消息延迟从50ms升至200ms。

操作步骤：

1. 新增一台服务器，部署第二个EMQX节点，配置静态集群（node1@192.168.1.10, node2@192.168.1.11）。
2. 在Nginx中配置MQTT负载均衡，使用一致性哈希（hash $remote_addr）保证客户端会话固定。
3. 将设备端Broker地址改为负载均衡器地址，逐步重启设备（分批进行，避免同时重连造成雪崩）。
4. 验证：在集群中随机kill一个节点，观察客户端是否在5秒内重连到另一节点，消息是否丢失（QoS1下可能有重复，但不会丢失）。

结果：集群后单节点CPU降至40%，延迟稳定在80ms。但发现一个问题：当节点1宕机时，节点2上的连接数瞬间翻倍，导致CPU短暂飙升至90%。后来通过限制单节点最大连接数（EMQX_LISTENER__TCP__EXTERNAL__MAX_CONNECTIONS=50000）并增加第三个节点解决。

复盘经验：集群扩容时，要预留30%的冗余容量，否则故障转移时可能引发雪崩。另外，客户端重连机制必须配置指数退避（如初始1秒，最大60秒），避免所有设备同时重连。

3.3 安全配置：认证、授权与加密

3.3.1 安全威胁模型

MQTT Broker面临的主要威胁包括：未授权访问（设备伪造）、消息窃听（明文传输）、消息篡改、拒绝服务（连接风暴）。在告警系统中，如果攻击者伪造设备上报“正常”状态，会导致真实告警被淹没；如果窃听告警消息，可能泄露生产数据。

3.3.2 安全配置清单

3.3.3 实战配置示例（EMQX）

# 启用TLS（emqx.conf）
listeners.ssl.external {
  bind = "0.0.0.0:8883"
  ssl_options {
    cacertfile = "/etc/emqx/certs/ca.pem"
    certfile = "/etc/emqx/certs/server.pem"
    keyfile = "/etc/emqx/certs/server.key"
    verify = verify_peer
    fail_if_no_peer_cert = true
  }
}

# 启用ACL（emqx-acl.conf）
{allow, {user, "dashboard"}, subscribe, ["$SYS/#"]}.
{allow, {ipaddr, "127.0.0.1"}, all, ["$SYS/#", "#"]}.
{deny, all, subscribe, ["$SYS/#"]}.
{allow, all}.

3.3.4 常见误区与总结

• 误区1：内网环境不需要TLS。实际上，工厂内网也可能有恶意软件或员工误操作，明文传输的告警消息可能被篡改，导致误告警或漏告警。
• 误区2：所有设备使用同一个用户名/密码。一旦密码泄露，攻击者可以订阅所有Topic。应该为每个设备或设备组分配独立凭据。
• 误区3：只做认证不做ACL。认证只能确认“你是谁”，ACL才能控制“你能做什么”。没有ACL，任何合法用户都能订阅所有告警Topic。
• 误区4：忽略速率限制。当设备固件bug导致频繁重连时，如果没有速率限制，Broker可能被连接风暴打垮。

总结复盘：安全配置不是一次性工作，需要定期审查证书有效期、ACL规则、设备凭据。建议每季度做一次安全审计，检查是否有异常连接、异常订阅行为。在告警系统中，安全的核心目标是保证告警消息的机密性、完整性和可用性，三者缺一不可。