为什么传感器采集不能只写一个循环
在实验环境中，每隔几秒读取一次设备并写入数据库，看起来已经完成了数据采集。但系统一旦运行数周，就会遇到串口短暂断开、网络抖动、设备时间漂移、磁盘写满和进程重启等问题。真正可靠的采集程序，需要把“读取成功”扩展为一条可恢复的数据链路。
边缘节点的价值在于靠近数据源。它不仅减少上行流量，还能在云端不可用时继续工作。因此架构设计的重点不是追求复杂，而是明确每个阶段失败后数据会留在哪里、何时重试以及如何避免重复。
为每条数据建立稳定身份
一条测量记录至少应包含设备标识、采集时间、指标名称、数值和质量状态。不要只依赖数据库自增编号，因为同一条数据在断网后重新上报时可能获得新的编号，最终形成重复记录。
更稳妥的方式是根据设备、采集时间和本地序列号生成唯一键。服务端写入时使用幂等语义：唯一键已存在则确认成功，而不是再次插入。这样客户端即使没有收到确认而重试，也不会污染历史数据。
采样线程与上传线程解耦
采样操作应尽量短，只负责与设备通信、校验原始值并写入本地队列。网络上传由独立工作线程处理。如果上传接口变慢，采样线程仍能按计划读取设备，不会因为一次 HTTP 超时错过后续数据。
本地队列可以从轻量数据库开始。相比只放在内存里，持久化队列能承受进程崩溃和设备重启。每条记录保存待发送、发送中和已确认状态，启动时把长时间停留在发送中的记录恢复为待发送。
合理设计批量上传
逐条发送实现简单，但网络和协议开销较大。可以按数量或时间窗口组成小批次，例如累计几十条或等待数秒后上传。批次不宜过大，否则单条异常会让整个请求难以定位，也会增加失败重传的成本。
服务端返回结果时，最好明确指出每条记录的处理状态。对于格式错误的数据标记为不可重试；对于限流和临时故障则保留在队列中，按照退避策略稍后处理。
退避重试要设置上限
固定间隔重试会在网络恢复前持续制造请求。指数退避可以让等待时间逐步增长，并增加少量随机抖动，避免大量节点在同一秒重新连接。达到最大间隔后保持稳定频率即可，不必无限增长。
重试次数不应决定是否删除原始数据。超过次数的记录可以转入隔离区并报警，等待人工分析。只有服务端明确确认接收，或按照数据保留规则完成归档后，才能清理本地副本。
时间戳需要区分采集与接收
传感器数据通常至少有两个时间：设备实际采集时间和服务端接收时间。两者都应保留。只记录接收时间会把断网期间积压的数据全部显示在网络恢复时刻，破坏趋势分析。
边缘节点可以通过可信时间源定期校准，但不要假设时钟永远准确。当系统发现时间突然跳变时，应记录事件并给后续数据附加质量标记。对要求严格的场景，还可以记录单调时钟间隔用于辅助排序。
数据质量校验放在边缘侧
边缘节点适合完成范围校验、格式转换和明显异常识别。例如温度传感器返回不可能的极端值时，不要直接丢弃，而是保留原始值并标记为无效。这样既不会影响正常统计，也能帮助判断设备是否损坏。
校验规则需要版本号。规则调整后，历史数据使用的是哪一版逻辑应当可以追溯，否则同一个数值可能在不同时间得到不同结论，却无法解释原因。
磁盘容量必须可预测
本地缓冲意味着磁盘会在长时间断网时持续增长。可以根据采样频率、单条记录大小和最长离线时间计算最坏容量，并设置警戒线。到达警戒线后，优先保留关键指标，同时降低非关键指标采样频率。
日志同样需要轮转。很多边缘设备并不是被业务数据写满，而是调试日志无限增长。日志应限制单文件大小和保留天数，并把错误摘要作为指标上报。
用状态机描述上传过程
一个清晰的状态机比零散的布尔字段更容易维护。记录从待发送进入发送中，收到确认后进入已完成；临时失败回到待发送并增加下次执行时间；永久失败进入隔离状态。
状态迁移可以概括为：待发送进入发送中，成功后进入已确认；临时失败回到待发送；不可恢复的数据进入隔离区。状态迁移与数据库写入应在事务中完成，避免进程恰好在更新一半时留下无法解释的状态。
监控指标应该围绕积压设计
采集系统最重要的运行指标不是请求总量，而是队列长度、最老待发送记录的年龄、连续失败次数和本地剩余空间。队列短暂增长可能正常，但最老记录持续变旧说明系统已经无法追上实时速度。
同时记录每类失败原因的数量，能快速区分设备通信故障、网络故障和服务端拒绝。告警信息直接包含节点、队列年龄和最近错误，比只发送“上传失败”更有行动价值。
从断网演练验证设计
上线前可以主动断开网络，让节点继续采集一段时间，再恢复连接。检查数据是否完整、顺序是否合理、服务端是否出现重复，以及队列能否平稳清空。随后重启进程，验证发送中记录能否恢复。
可靠的边缘采集不是保证每次请求都成功，而是保证任何一次失败都不会让数据无声消失。把身份、缓冲、重试、时间和监控这些基础能力做好，小型节点也能长期稳定运行。