封面为 AI 概念示意。
MQTT 和 HTTP 分别适合什么
频繁上报、有多个订阅方、设备需要接收异步状态或事件时，可优先评估 MQTT。批量导入、历史查询、配置文件下载或已有 API 基础设施时，HTTP 更容易接入。实际项目可以用 MQTT 报告状态、用 HTTPS 补传历史批次，同时给两路数据使用同一业务事件编号。选择依据应包括消息频率、在线会话成本、离线时长、网络条件和服务端运维能力。
| 场景 | 首选评估方向 | 需要约定 |
|---|---|---|
| 在线遥测和事件广播 | MQTT 发布与订阅 | 主题、权限、频率、消息大小 |
| 日报和历史记录补传 | HTTPS 批量接口 | 批次边界、部分成功、重复请求 |
| 配置查询和文件下载 | HTTPS | 版本、摘要、缓存与授权 |
| 状态变化提醒 | MQTT，业务端记录已处理事件 | 新鲜度、掉线标记、顺序 |
| 设备控制 | 任务编号与业务回执独立设计 | 过期、重复、拒绝与最终状态 |
QoS 与业务确认的区别
MQTT 的 QoS 描述协议交付语义。QoS 1 允许重传，接收端需要能处理重复消息。QoS 2 的协议保证有范围，不能据此推断订阅程序写数据库、生成告警或触发设备动作也只执行一次。保留消息适合发布最后已知状态，消费者要根据时间戳和有效期判断是否陈旧，尤其应避免把保留消息直接当作可执行的新命令。OASIS MQTT 5.0 规范
HTTP 的幂等语义描述重复请求对资源的预期效果。把普通 POST 发两遍并不会自动去重，客户端在超时后往往无法判断服务端是否已写入。上传事件时可以使用稳定事件 ID，并约定相同 ID、相同内容返回已存在，相同 ID、不同内容进入冲突处理。这样服务器已落库但响应丢失时，设备重发能安全收敛。RFC 9110 HTTP 语义
断网以后，哪些数据必须找回来
把设备数据分成状态、趋势、告警和工单。状态通常可以被新的有效状态覆盖，趋势根据业务要求保留原始点或定时聚合，告警与工单往往需要独立编号和明确确认。缓冲容量取决于平均写入速率、最长断网时间和单条占用，还要留出索引、存储放大及补传期间的新数据空间。超过容量时要能说明保留优先级、告警方式与丢弃计数。
断线恢复后先恢复当前状态，再按限速和批次补送历史数据。业务端同时存采样时间、接收时间和时间可信度，离线事件进入历史时间线，不直接刷新设备当前状态。若设备时钟跳变，可按开机代次和递增序号恢复局部顺序。对账时用事件数量和缺号段，比单看连接在线率更有效。
交付前怎么测
| 工况 | 检查项 |
|---|---|
| 服务端成功处理但响应丢失 | 设备重试，业务数据只生成一份 |
| 设备离线到缓冲接近上限 | 关键告警和普通采样按约定保留，满盘可观测 |
| 离线期间下发过期任务 | 恢复上线后标明过期并不执行 |
| 大量设备同时恢复 | 有退避和限流，在线状态不被历史补传淹没 |
| 时钟回拨或重启 | 事件顺序可解释，记录仍可对账 |
离线缓存怎么估算
假设每十秒生成一条约二百五十字节的原始记录，一天约八千六百四十条，数据体约二点一六兆字节。三天离线时约六点四八兆字节，还要加索引、事务日志、加密和重发空间。若客户还要存照片或波形，应该单独用实际数据估算，不能按普通遥测点的尺寸规划。再用实测网络带宽推算补传时长，给实时消息留带宽和业务优先级。
控制命令也需要单独设计。以远程切换工作模式为例，命令应包含任务编号、目标状态与有效期，设备先判断当前模式、权限和本地条件，再明确返回已接受、执行完成或拒绝原因。手机界面可展示「已发出」和「设备已执行」两个状态，现场人员看到网络异常后也能判断是否需要人工核对。
小型样机需要同时实现两种协议吗？
可以先用一种协议验证核心路径，同时把设备身份、事件 ID、时间与回执规则定义清楚。需要对接第三方平台或追加批量历史接口时，再按接口边界扩展。
MQTT 和 HTTP 谁更省电？
取决于连接保持、唤醒频率、TLS 握手、报文大小、网络重连和无线模块功耗。可以用两套候选策略在目标网络上测完整唤醒周期，比较平均能耗和上报延迟。
如果正在做设备后台、边缘网关或软硬件联调，可以提供设备数、上报量、最长离线时长以及哪类数据不能丢。延伸阅读见工业设备离线追溯开发方案。联系初拓科技
近期评论