一、为什么选择 MQTT
本项目是面向 工商业储能柜（PCS + BMS + 消防 + 电芯）的本地能量管理系统（EMSU），对下接设备，对上接云端。「设备 ⇄ EMSU ⇄ 云端」链路上选择 MQTT，核心原因有四点：
1.1 业务模型与协议模型天然契合
新能源 / 储能行业有几个非常特殊的需求，MQTT 几乎是量身定制的。
1.2 行业场景特征
特征 | 说明 |
|---|
设备分布广 | 风电场、光伏电站、储能柜常在偏远地区 |
网络条件差 | 4G 信号弱、基站切换、偶发断网是常态 |
设备数量大 | 单电站数百台 PCS / BMS / 电芯采集器 |
控制指令重要 | 调度指令、充放电策略、紧急停机不可丢 |
数据采集频繁 | 状态上报毫秒级、秒级 |
生命周期长 | 设备运行 10-20 年，协议必须稳定演进 |
多业务并行 | 监控、告警、控制、OTA、运维消息并存 |
安全要求高 | 电网级设备被恶意控制后果严重 |
1.3 MQTT 的针对性优势
① 海量设备并发接入
100MW 储能电站可能有 2000+ 采集节点，MQTT 单 Broker 可轻松应对 2 万并发
② 弱网与移动网络适应性
能力 | MQTT 表现 |
|---|
网络抖动 | 自动重连，无需应用层处理 |
基站切换 | 设备无需重新配置，自动恢复 |
偶发断网 | QoS 1/2 保证消息不丢，重连后补发 |
高延迟网络 | 比 HTTP 轮询延迟低 10 倍 |
③ 多业务消息隔离与路由
通过主题设计，云端订阅 ems/# 一次性获取所有数据，特定指令发布到特定主题即可定向下发。
⑤ 跨厂商互操作性
不同厂商设备可接入同一 Broker，新厂商接入只需支持 MQTT 主题约定。
⑧ 与电力行业标准契合
二、
2.1 定位
协议 | 定位 |
|---|
HTTP 轮询 | 隔几秒询问云端有没有新消息，90% 空跑 |
TCP 长连接 | 保持一条 TCP 连接，自己定消息格式收发 |
MQTT | 自连 Broker，按主题发布订阅 |
2.2 维度对比
维度 | HTTP 轮询 | TCP 长连接 | MQTT |
|---|
底层 | HTTP/HTTPS（TCP 短连接，每次请求重建） | TCP 原生长连接 | TCP 长连接 |
通信模型 | 请求‑响应，客户端主动拉取 | 双向原始字节流，可双向收发 | 发布‑订阅 (Pub/Sub)，服务端推送 |
消息推送 | 无法真正推送，只能客户端定时拉 | 可双向推送，需自己封装逻辑 | topic 订阅 |
消息大小 | HTTP 请求头体积大，开销高 | 裸字节，开销极小 | 头部极小，最小仅 2 字节 |
弱网 / 不稳定网络 | 差，频繁建立销毁连接 | 需自己实现心跳、断线重连、粘包分包 | 内置 keepalive 心跳、断线重连逻辑、遗嘱消息 |
QoS 可靠性 | 无，http 失败只能客户端重试 | 自己实现（ACK、重传、丢包检测） | 内置 QoS0/QoS1/QoS2 三级可靠 |
服务端压力 | 大量短连接，大量握手开销 | 连接数高，内存占用大，管理复杂 | 设备并发友好，broker 专门优化 |
三、MQTT 在工商业储能场景的应用
3.1 工商业储能的业务特征
单站规模 0.5~5 MW / 1~10 储能柜，中型居多
单柜包含 PCS、BMS、消防主机、温控、电芯采集器
部署在工厂园区、商业楼宇、光储充一体站、数据中心、微电网
业务诉求：削峰填谷、需量管理、电费优化、备电、安全监控、远程运维
网络：4G / 以太网 / Wi-Fi，偶有弱网
3.2 数据流模型
EMSU 的
关键特性在储能中的用法
特性 | 用法 |
|---|
QoS 0 | 周期状态上报（bms/pcs realtime），允许丢帧换最低带宽 |
QoS 1 | 普通控制指令、参数下发，至少送达 |
QoS 2 | 紧急停机、并/离网切换，绝对不可重复不可丢 |
主题通配符 | 运维订阅 emsu/+/+/alarm 一次收全站告警 |
遗言消息 | 设备非正常掉线时 Broker 自动发 connection/offline，秒级感知 |
持久会话 | 断电数小时恢复后可补齐期间告警 |
Keep Alive | 30~60s，1.5 倍超时即判定离线 |
TLS + 双向证书 | 防中间人、防伪设备接入 |
主题 ACL | 设备只能 pub 自己的 cabinet 主题、sub cloud/<自己>/#，最小权限 |
Retain | 关键配置常驻主题，新订阅者立即拿到 |
MQTT 5.0 共享订阅 | 云端多分析节点负载均衡 |
3.4 与本项目技术栈契合
组件 | 与 MQTT 的契合 |
|---|
Paho MQTT C++ (paho-mqttpp3) | Eclipse 官方客户端，跨平台、工业级验证 |
Protocol Buffers | MQTT payload 二进制编码，带宽小、向前兼容 |
RSA-OAEP + AES-256-GCM + RSA-SHA256 | 补齐 MQTT「明文 + 无签名」短板，端到端加密 |
Qt 信号槽 | MQTT 异步事件 → Qt 信号 → UI/Service 解耦 |
SQLite 本地库 | 告警/历史落本地，配合上行补传 |
3.5 与行业合规契合
GB/T 36558 储能系统技术规范：数据可追溯、不可篡改 → 签名 + 加密
GB/T 22239 ：通信加密、身份认证 → TLS + 双向证书
电网调度对接：调度指令可靠送达 → QoS 1/2
消防/安全监管：告警实时 → MQTT 推送 + 遗言
四、总结
问题 | 结论 |
|---|
为什么选 MQTT | 双向 + 实时 + 海量 + 弱网四重压力下模型最匹配、生态最成熟、长期最稳 |
为什么不选 HTTP 轮询 | 无法推送、流量浪费、无 QoS、无主题路由，不适合工业遥测 |
为什么不选裸 TCP 长连接 | 等于重造阉割版 MQTT，毫无必要 |
