工程要点
- 未发送数据必须由设备本地持久保存。
- 每条记录都需要事件时间、序列、模式版本和稳定 ID。
- 队列已满是必须公开的运行状态，不能静默删除。
网络负责传输，不是历史存储
路由器、证书、DNS、移动链路和维护都会造成中断。控制应继续在本地运行，遥测层必须准确知道哪些数据尚未送达。[1][4]
让记录在重放后仍能被识别
设备 ID、信号 ID、值、质量、事件时间、序列、模式版本和稳定记录 ID 共同保证重放正确。[6][5]
- 按序列或 ID 去重
- 标记时钟质量
- 对载荷模式进行版本管理
- 显式传递陈旧和离线状态
使用有界且具事务性的本地日志
嵌入式数据库或只追加日志可以统一处理排序、确认、压缩和崩溃恢复。[2][3]
| 状态 | 本地 | 云端 | 动作 |
|---|---|---|---|
| 排队 | 已持久化 | 未知 | 使用相同 ID 重试 |
| 传输中 | 已持久化 | 待确认 | 超时后重试 |
| 已确认 | 已持久化 | 已提交 | 可压缩 |
| 已过期 | 按策略 | 未发送 | 统计损失 |
重放历史，但不要阻塞实时状态
为当前健康状态和报警保留带宽，再以受控批次清空历史积压。[1][5]
MQTT QoS 1 允许重复。业务层 exactly-once 仍需要稳定 ID 和幂等写入。[1]
存储满之前先确定策略
根据可信最长中断、数据量、写放大和余量计算容量，并按信号类别定义保留或丢弃规则。[4]
- 公开队列年龄、字节和丢失数
- 隔离运行时与存储阻塞
- 明确保留规则
- 测试每个阶段的断电
真正有意义的断网测试
- 设备运行时断开上行
- 分别重启服务和控制器
- 达到最大中断时间后恢复
- 检查时间、顺序与去重
- 重放期间保持实时状态
- 主动填满存储至各阈值
常见问题
MQTT QoS 1 足够吗？
不够。它没有定义本地持久日志、保留策略、模式或端到端去重。
重放必须全局有序吗？
通常按设备和信号流有序即可，可避免不相关信号之间的队头阻塞。
本地存储需要多大？
应从最大可信中断、数据量、保留类别和经过测试的余量推导。
资料来源与标准
- MQTT Version 5.0OASIS Open
- Write-Ahead LoggingSQLite
- Transaction control languageSQLite
- NIST SP 800-82 Rev. 3: Guide to Operational Technology SecurityNational Institute of Standards and Technology, September 2023
- Prometheus Remote-Write 2.0 specificationPrometheus
- RFC 3339: Date and Time on the InternetIETF
BootCtrl Engineering 于 2026年7月26日 最后核查本文技术论述与来源链接。所有产品表述均对照当前实现代码库；路线图工作不会被描述为已发布能力。
