边缘网关的本地缓存怎么选：SQLite、队列文件与时序库的取舍

结论：车间边缘网关做断网缓存，数据量不大、要求简单可靠时，首选SQLite（WAL模式）；纯追加的高频点位可用按时间分段的队列文件；需要本地查询聚合再考虑嵌入式时序库。选型的核心是三点：写入吞吐、掉电安全、补传时的顺序与去重。

一、缓存要解决什么问题

设备采集到网关，再上传云端，中间链路（4G、专线、厂区WiFi）随时可能断。网关必须在断网期间不丢数据，恢复后按顺序补传，并保证云端不重复入库。

二、三种方案对比

1. SQLite（WAL模式）：支持事务，掉电后一般可恢复；单文件易备份；写入几千条每秒量级通常够用，建议批量事务提交（例如每100条或每200毫秒提交一次）。缺点：长时间运行需定期清理并VACUUM，避免文件膨胀。
2. 追加队列文件：每个时间段一个文件（如每10分钟），写入最快；补传时按文件顺序读取，上传成功后删除整个文件。缺点：需要自己处理文件损坏、半行记录，掉电时最后一段可能不完整，要有校验（行尾CRC或长度前缀）。
3. 嵌入式时序库：本地可做降采样、聚合查询，适合边缘侧要出本地看板的场景；缺点是占用资源更多，低配网关（内存几百MB）可能吃紧。

三、补传设计的关键字段

每条记录建议包含：设备ID、点位ID、采集时间戳（毫秒，UTC）、值、质量码、本地自增序号。云端用“设备ID+点位ID+时间戳”作为幂等键，重复上传直接忽略。补传时按序号升序、分批（如每批500条）发送，收到确认后再标记已发送，不要发送即删除。

四、容量与保留策略

估算公式：点位数×采样频率×单条字节数×需要覆盖的断网时长。例如1000点、每秒1次、每条约50字节，每小时约180MB（按公式计算）。再按存储剩余量设定上限，超限时优先保留报警与状态变化类数据，丢弃高频原始值并记录丢弃日志。

五、上线前自测清单

• 拔网线30分钟再恢复，核对云端条数与网关一致。
• 补传期间同时有实时数据，确认实时数据优先、补传限速不拖垮链路。
• 强制断电三次，检查数据库完整性。
• 修改网关系统时间，观察时间戳是否异常（建议用单调时钟辅助排序）。

FAQ

问：缓存满了怎么办？答：按预设优先级丢弃，并上报告警。

问：补传会不会把云端写爆？答：限速并分批，设置每秒上限。