物联网 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 或时间戳实现幂等，防止重复执行