Raspberry Pi向Azure IoT Hub传数丢样的双进程方案可行性咨询

你提出的双进程+CSV轮转缓冲的方案完全可行。
你当前遇到的丢数本质是采集、上传逻辑强耦合：10次/秒的采样间隔是100ms，而Azure IoT Hub单次同步发送的平均网络延迟在300-600ms，阻塞期间的采样数据没有缓存就会直接丢失，刚好对应你观察到的每次丢5个左右采样点的现象。双进程方案把采集和上传拆成两个独立流程，用本地持久化存储做缓冲，从架构上切断了网络延迟对采样流程的阻塞，完全匹配你的场景需求。

直接裸写双进程读写CSV很容易踩文件锁、半写文件读损坏、SD卡写满的问题，落地时必须做以下处理：

• 做文件状态原子切换：采集进程写数据时，文件统一用.tmp临时后缀，攒够10秒数据、写完所有内容并关闭文件句柄后，再通过原子重命名操作把后缀改成.csv；上传进程只扫描目录下后缀为.csv的文件，从根源避免读到还在写入的半完成文件。
• 上传成功再删文件：上传进程读完CSV内容、确认Azure IoT Hub返回接收成功响应后，再删除对应CSV文件；如果遇到网络闪断、上传失败，不要删文件，下次轮询时重试即可，重试建议用指数退避策略（首次等1s，第二次等2s，最长等待30s），避免高频请求打满网络。
• 批量发送降延迟：单份10秒的CSV只有100条采样数据，不要逐条调用发送接口，直接用Azure IoT Hub SDK的批量发送接口传整批数据，能把单批上传延迟降到100ms以内，还能节省IoT Hub的消息配额。
• 加存储阈值保护：给待上传的CSV文件设数量上限，比如最多保留100个待传文件（对应约16分钟的缓存数据），如果超过阈值就打本地日志告警，避免长时间断网时文件把树莓派SD卡写满导致系统崩溃。
• 采集进程别加任何网络逻辑：采集进程只做读传感器、写本地文件两件事，不要在这个进程里加任何网络请求、打印过量日志的逻辑，保证采集循环的耗时稳定在10ms以内，就不会再出现采样阻塞丢数的问题。

如果你不想手动处理文件轮转、锁冲突的逻辑，可以直接用本地SQLite数据库做缓冲层：采集进程直接把带时间戳的采样数据写入SQLite，上传进程按主键顺序读取未上传的记录批量发送，发完把对应记录标记为已上传即可，逻辑比文件操作更简洁，持久化可靠性也更高。
不建议用纯内存跨进程队列做缓冲，树莓派如果意外断电，内存中未落盘的数据会直接丢失，不适合传感器数据采集场景。

内容的提问来源于stack exchange，提问作者Georgy