采集数据不丢的秘密：SQLite + Outbox 断点续传

“读到了就转发”的方案在网络上必然丢数据。要做到不丢，必须把“数据”与“发送”解耦：先落库，再异步投递，失败就重试。这就是 Outbox 模式。

一、写路径：一次采集做两件事

1. 采集到的点位写入本地 SQLite（按天分表 + 保留策略），用于历史查询与补传；
2. 同一拍的数据写入Outbox 持久队列（先落库再投递），投递成功才删除。

这样“进程崩溃、服务器断电”都不影响：重启后队列里还躺着没发出去的消息。

二、发送路径：失败会怎样

• HTTP 非 2xx / MQTT 断连 → 该条计一次失败；
• 按 2^n 指数退避（1s、2s、4s…封顶），避免打爆目标；
• 超过最大尝试次数 → 标为 dead 死信，保留现场可人工“重放”；
• 进程重启 → 启动时把待发消息立即重新排队续投。

三、监控这些数字

pending（待投递，长期应≈0）
dead（死信，应≈0）
sent（近 7 日成功发送数，随采样增长）

运行监控页与转发通道页可实时看到这几个指标——它是“可靠性”的直接证据。

四、为什么不用内存队列或直接推

内存队列丢在“重启”；直接推丢在“网络抖动”。对工业场景，宁可慢一点、绝不丢点。Outbox + SQLite 的成本只是一张表，收益是全程可审计、可重放。