物联网 MQTT订阅性能优势
MQTT 订阅 推送
服务端不需要知道硬件设备的 IP 地址，也不需要关心设备在哪个网络、有没有换 IP。设备主动告诉 Broker "我想订阅某个主题"，之后所有发往该主题的消息，Broker 都会自动转发给它。服务端只管往主题上发指令，设备自己"认领"消息
Socket 指定 IP 推送
服务端必须明确知道设备的 IP 和端口，并且设备往往需要有一个固定或可访问的公网 IP（或通过反向连接、内网穿透辅助）。每次推送都是直接建立 Socket 连接到那个 IP 的设备。服务端必须维护一张"设备 → IP"的映射表，设备位置变了就得更新
详细对比表
| 维度 | MQTT 订阅（间接推送） | Socket 指定 IP 推送（直接推送） |
|---|---|---|
| 设备定位 | 设备连接 Broker 即可，IP 可动态变化 | 服务端必须知道设备当前的 IP 和可访问端口 |
| 网络要求 | 设备只需能访问 Broker（通常是云或内网固定主机） | 设备通常需要公网 IP 或服务端与设备在同一内网（或做内网穿透） |
| 服务端复杂度 | 简单：服务端发布消息到主题，不关心设备列表 | 复杂：服务端需维护在线设备 IP 表、处理设备掉线/重连、处理 NAT 穿透 |
| 扩展性 | 高：一个主题可被任意数量设备订阅 | 低：每增加一台设备，服务端可能需要修改推送逻辑 |
| 防火墙/NAT | 友好：设备主动发起连接，无需在路由器上开端口 | 困难：设备作为 TCP 服务端监听端口，通常需要端口映射或反向代理 |
| 离线消息 | 支持：Broker 可为离线设备缓存消息（QoS 1/2） | 需自行实现：设备不在线时消息直接丢失或需自行持久化 |
| 一对多推送 | 天然支持：发布一条消息，所有订阅者同时收到 | 需循环给每个 IP 建立连接发送，效率低 |
| 安全性 | 集中认证：在 Broker 上统一管理设备认证和 TLS | 分散认证：每个设备需单独处理安全握手（或依赖内网信任） |
具体场景
控制 100 台智能灯
-
使用 MQTT 订阅
每盏灯上电时，连接 MQTT Broker（例如 mqtt.example.com），订阅主题 light/cmd
服务端发送一条消息到主题 light/cmd，内容为 {"state":"off"}
Broker 将这条消息复制 100 份，发送给所有订阅了该主题的灯
完全不需要知道灯的 IP 地址 -
使用 Socket 直接指定 IP 推送
服务端必须提前知道或动态获取每盏灯的 IP 列表（例如灯主动上报 IP）
当需要关灯时，循环遍历 100 个 IP，对每个 IP 建立 Socket 连接（例如 192.168.1.101:8888），发送 off 命令
如果某一盏灯的 IP 变化了（例如 DHCP 重新分配），推送就会失败
如果灯处在不同子网，服务端可能无法直接连接
什么时候用 Socket 直接推送
极低延迟的点对点通信：例如两个设备在同一局域网内，需要微秒级响应（MQTT 经过 Broker 会多一跳）
不需要主题路由、离线缓存等高级特性：例如一个控制端对单个执行器的私有协议
硬件资源极度受限：跑不起 MQTT 协议栈（但通常也会选择更轻量的 UDP 或 CoAP）MQTT/订阅模式 设备端带来信息干扰
精细的主题命名与订阅粒度
主题包含设备 ID 或类型：device/light/001/cmd 而不是 light/cmd
通配符使用克制：尽量用 + 而非 #。例如设备只需温度数据，订阅 sensor/+/temperature 而不是 sensor/#QoS 与消息速率控制
对高频率发布的 topic，在 Broker 端配置消息速率限制（如 EMQX 支持限流）
设备端可根据需求忽略部分消息（例如每 10 秒只处理一次最新值）设备端消息过滤与幂等设计
设备在回调函数内根据消息 payload 内容二次过滤（如只处理 state=ON 的消息）
使用消息 ID 或时间戳实现幂等，防止重复执行