华东一家做汽车线束的厂子去年夏天出过一次不大不小的事故。车间那台汇聚交换机做固件升级，重启了两分十七秒。恢复得很顺利，PLC 没停，网关的指示灯正常闪，当班的人压根没察觉。第二天早上工艺工程师打开云端报表，发现 OEE 曲线在 14:23 到 14:25 之间豁了个口子，两分钟数据是空的，而且补不回来。
网关日志后来被翻出来看，问题不在网络，在网关自己。那台边缘盒子的缓冲是放在内存里的环形队列，深度按 30 秒设计。断网之后队列在半分钟内就写满了，后面采上来的数据被新数据一轮轮覆盖。等链路恢复、网关重连成功，它干的事是"从当前时刻重新开始上报"，而不是"把断网期间攒下来的补上去"。两分钟的数据就这么没了，连个报错都没留。
更麻烦的是第二层损失。因为这两分钟正好跨过一次换型，班次产量核算、设备开动率、能耗分摊三个口径对不上，工艺和财务对了一整天账。一次两分钟的交换机重启，代价是三个人一天的工作量。这类事在工业现场不算稀奇，而且绝大多数不是网络质量问题，是架构问题：
缓冲放在内存里，掉电或进程重启即丢，断网时间一长必丢。
缓冲落了盘，但没有水位与老化策略，长时间断网后被新数据循环覆盖。
补传上来的数据用的是"接收时刻"而不是"采集时刻"的时间戳，落到错误的时间窗口，报表按窗口聚合时整段被判无效。
补传没有限速也没有去重，一次性灌进接收端，把磁盘和数据库打挂，连带把正在写入的实时数据一起拖垮。
网关和服务器各说各的时间，两边时钟差了几分钟，补上来的数据对不上工艺曲线。
这五条里任何一条单独出现，表现都是同一句话：云端报表少了一段。要真正解决，得把整条链路摊开，一段一段看。
工业数采听着复杂，拆成段其实就六跳，每一跳都有独立的失效模式，也都有独立的责任方：
第一跳，PLC / 仪表 → 数采网关。这一段走的是现场总线或工业以太网，常见的是 Modbus TCP、Modbus RTU、OPC UA、Profinet、S7 协议，仪表类还有 4-20mA 经采集模块转换。这一跳丢数的典型原因是轮询周期大于数据更新周期（采得比变得慢）、从站超时重试、串口波特率与干扰。注意这一跳丢的数据，后面所有环节都救不回来。
第二跳，网关内部的处理与缓冲。网关要做协议解析、点位映射、工程量程转换、死区过滤、本地缓存。这一段丢数的原因就是前面说的：缓冲在内存、缓冲被覆盖、进程崩溃后队列丢失。这是断网丢数最主要的源头。
第三跳，网关 → 车间网络。交换机、VLAN、无线 AP、车间防火墙。这一段的问题是广播风暴、交换机端口协商失败、ARP 表异常、VLAN 隔离把网关和出口隔开了。
第四跳，车间网络 → 公网 / 企业互联 → 机房入口。这一段是出口带宽、NAT 会话数、VPN 隧道稳定性、运营商链路质量的组合。这一段丢数表现为连接中断或重传超时，也是"断网"这个词最常被指的地方。
第五跳，机房服务器接收端。接收程序、消息队列、写入缓冲、时序库。这一段丢数的原因是接收端写入阻塞导致上游队列堆积、进程重启时内存队列丢失、磁盘写满后写入失败但没有正确返回错误码。
第六跳，数据库 / 时序库 → 报表与上层系统。这一段不丢数据，但会"看起来丢"：时区配置错误、时间窗口边界的闭开区间不一致、聚合任务漏跑、去重规则把合法数据误删。
把链路画出来的意义在于，当报表说"少了一段"，你第一件事不是去查网络，而是按这六跳倒着排查：先确认第六跳的聚合任务有没有跑、第五跳的接收端日志有没有报错、第四跳的链路监控有没有中断记录，这才轮到查网关。大多数情况下，问题在第五跳和第二跳，不在第四跳。
按现场经验排个序，断网相关的数据丢失基本集中在三个位置。
这是第一名。很多边缘盒子出厂默认的缓冲是"内存队列 + 固定深度"，深度单位还是"条数"而不是"字节数"，比如 10 万条。听起来很多，但 5000 点、500 毫秒采样下每秒就是 1 万条，10 万条只够撑 10 秒。断网超过 10 秒，剩下的全丢。
正确的做法是按字节和按时长双约束：缓冲容量必须按"最坏断网时长 × 每秒字节数"来定，而且要有水位告警（比如 60% 告警、85% 开始老化丢弃最老的冷点位、95% 触发本地告警灯）。老化策略要按点位重要性分级，关键工艺点位撑到最末才丢，辅助监测点位先丢。
这是第二名，也是断网恢复时最容易爆的雷。假设网关规规矩矩攒了一小时数据，链路恢复后以 10 倍稳态速率补传。如果接收端是按单条事务写入的关系库，写入 IOPS 会瞬间打满，WAL 刷盘排队，响应变慢，接收端的 TCP 接收窗口收缩，网关侧又判定超时重传，形成恶性循环。这时候不仅补传的数据进不来，连实时数据也开始丢。
接收端必须自己有节流能力：按写入能力反推能接受多大的补传速率，超了就让网关慢点发。这个逻辑要在协议层就定好，别等现场出了问题再改。
这是第三名，也是最隐蔽的一个。因为它不表现为"数据没了"，而表现为"数据在但不能用"。网关离线三天，RTC 漂了 40 秒，补上来的数据时间戳整体偏移，跟同一时段的工艺曲线对不上，工程师看一眼就知道这数据不可信，整批作废。下一节单独讲。
很多厂商宣传"断网续传"，实际只做了其中一条或两条。要真正做到补得回来、补得对，三个条件缺一不可。
条件一：网关侧有本地持久化缓冲，不能只在内存里。缓冲要落在掉电不丢的介质上，最好是带掉电保护的 eMMC 或工业级 SSD，并配超级电容或小型 UPS，保证断电瞬间能把缓存页刷下去。判据很简单：把网关电源拔掉，等三十秒再上电，看断网期间攒的数据还在不在。只放在内存里的缓冲，一次现场检修拉闸就全没了。
条件二：缓冲有水位与老化策略。持久化缓冲不是无限大的，断网一天、一周的情况下必然要丢弃一部分。策略要明确：按点位优先级排队丢弃、按时间老化丢弃最老数据、水位到阈值就本地声光告警而不是静默覆盖。这里有个容易踩的坑——有些网关默认策略是"缓冲满就丢新数据"，对实时监控来说这反而更合理（保住最新状态），但对历史分析来说是灾难。策略要按业务定，不能按默认走。
条件三：补传的数据带原始采集时间戳，且接收端能幂等去重。时间戳必须是采集时刻，不是上报时刻，而且要带时区或统一为 UTC/Unix 毫秒。接收端要能识别"这条我收过了"，最简单的实现是把（点位 ID + 采集时间戳）作为唯一键，重复写入直接覆盖而不是插入。没有幂等，一次网络抖动导致网关重传，接收端就会出现两条时间戳相同的数据，聚合时被算成双倍产量。
这三条里，第一条决定能不能补，第二条决定补多少，第三条决定补上来的是不是可用数据。只做第一条的"断网续传"，等于把问题从"丢数据"变成"灌垃圾数据"。
工业数据跟普通日志最大的区别在于，它的价值高度依赖时间精度。一条温度值是几点几分几秒采的，决定了它属于哪个批次、哪次换型、哪个工单。时间错一秒，可能就归到错误的工艺段里去了。
联网状态下的对时。网关和服务器都要接入同一个 NTP 源，最好是厂区内部署的一台本地 NTP 服务器（用 GPS 或北斗授时），所有设备对它同步，而不是各自去同步公网时间池。同步间隔建议 5 到 15 分钟一次，时钟偏差超过阈值（比如 200 毫秒）就告警。别小看这个告警，它能提前发现晶振老化的硬件问题。
离线状态下的漂移。网关断网后只能靠板载 RTC 走时。普通 RTC 用的 32.768 kHz 晶振，受温度影响明显，典型精度在每月几十秒到几分钟量级，温度剧烈变化的车间里会更差。带温度补偿的 RTC 模块能好一个数量级，成本也就多几十块。如果你要应对"断网一整天甚至几天"的场景，这笔钱值得花。判断方法：把网关断网放置 72 小时，再和 NTP 源对比，看偏差是多少，按这个偏差乘以最长可能断网时长，就知道最坏情况下时间会错多少。
数据迟到（late arrival）怎么处理。这是时序库必须面对的问题。补传上来的数据时间戳是过去的，而聚合任务可能已经把那个时间窗口算完并落库了。处理方式有几种：一是时序库支持迟到写入并自动重算受影响的分段；二是给聚合任务留一个"迟到窗口"（比如延迟 10 分钟出报表，等迟到数据）；三是补传的数据打标记，走单独的回填流程，回填完成后触发对应时间段的重算。三种方式都要在上线前定好，否则补传完成却看不到数据，现场会以为又丢了。
工业数采选型最常见的错误是照着 CPU 核数挑机器。实际跑起来会发现，1000 个点的采集任务 CPU 占用可能不到 10%，瓶颈全在磁盘写入和时钟上。正确的做法是从点表出发反推。下面这套算式可以直接拿去用。
每秒数据点数 = 点位数 ÷ 采样周期（秒）。5000 个点、500 毫秒采样，就是 5000 ÷ 0.5 = 10000 点/秒。注意这里说的是"有效上报点数"，如果网关做了死区过滤（变化超过阈值才上报）或降频聚合，实际值会低不少，死区过滤在慢变量场景能砍掉 70% 以上的量，但快变量基本砍不动。规划时按未过滤的满负荷算，留余量。
按典型字节数估算（非实测，实际以你的点表与编码方式为准）：点位标识 4 字节、毫秒级时间戳 8 字节、数值 8 字节、质量位与状态 4 字节、存储引擎的行头与索引开销约 16 字节，合计约 40 字节/点。如果你的点位是字符串型或带多个附属字段，这个数要往上调；如果做了定点压缩或差分编码，会明显下降。
上行带宽 = 每秒点数 × 40 字节 × 1.3。那个 1.3 是协议封装开销：MQTT/HTTPS/TCP 的报文头、JSON 或 Protobuf 的字段名与括号、TLS 加密填充，通常占到 20% 到 40%，取 30% 做保守估计。用二进制协议和批量打包（一个报文装 100 条记录）能把系数压到 1.05 左右，用 JSON 单条上报则可能到 1.8。这是选型时最容易被忽略又最容易优化的一块。
每日有效字节 = 每秒点数 × 40 × 86400。落盘容量不能直接用这个数，还要乘一个冗余系数 2，用于覆盖索引、WAL、副本以及压缩段合并期间的临时空间。时序库压缩比通常不错，但压缩后的大小不能拿来规划磁盘，因为压缩前要有地方放，压缩合并过程中还要额外空间。再往上加 20% 的运维余量，用于备份、临时导出、索引重建。
缓冲容量 = 每秒字节数 × 允许的最长断网时长。这一条直接决定网关选型，也是采购时最该问厂商的一句话：你的盒子在满负荷下能缓存多久？
| 点位规模 | 采样周期 | 每秒数据点 | 上行带宽估算 | 每日数据量估算 | 保留 1 年的磁盘估算 | 服务器侧重 |
|---|---|---|---|---|---|---|
| 约 100 点 | 1 秒 | 100 点/秒 | 约 5 KB/s，约 0.04 Mbps | 有效约 0.35 GB，落库约 0.7 GB | 约 0.3 TB（含 20% 运维余量） | 入门级独服即可，重点做磁盘镜像与异地备份，别在 CPU 上花钱 |
| 约 1000 点 | 1 秒 | 1000 点/秒 | 约 52 KB/s，约 0.4 Mbps | 有效约 3.5 GB，落库约 7 GB | 约 3 TB（含 20% 运维余量） | 企业级 SSD 做数据盘，内存 32–64 GB 给写入缓冲与热段，双电源 |
| 约 5000 点 | 500 毫秒 | 10000 点/秒 | 约 520 KB/s，约 4 Mbps（补传峰值按 5 倍计约 20 Mbps） | 有效约 35 GB，落库约 69 GB | 约 30 TB（含 20% 运维余量） | NVMe 或企业级 SSD 阵列，内存 128 GB 起，万兆内网、双网卡绑定、写入分盘 |
以上为按典型字节数的估算方法示例，非实测数据，实际以现场点表与采样策略核算为准。
这套算式的用处不在于给出准确数字，而在于把讨论从"要不要上 16 核"拉回到"每秒写多少、写多久、断网能扛多久"。把这张表当成输入条件去对照机房侧的机型与存储档位，一万网络这类深耕 IDC 19 年（成立于 2007 年）的服务商，其机房侧的磁盘与内存档位可以作为接收端配置的对照参考，具体机型与价格需实时询价。
同样是 10000 点/秒，单条写入和批量写入对服务器的压力差着两三个数量级，这不是优化技巧问题，是能不能跑起来的问题。
单条写入的代价在于每一次事务都要走完整的流程：申请事务 ID、写 WAL、刷盘确认、更新索引、提交。机械盘的顺序写 IOPS 大致在几百量级，SATA SSD 在数万量级，NVMe 能到数十万。看起来 NVMe 完全扛得住 10000 次/秒，但那是理想条件下的裸盘数字，落到数据库上还有锁竞争、索引维护、WAL 组提交、后台刷页，实际能稳定支撑的单条事务 TPS 往往只剩几千。5000 点、500 毫秒的场景，单条写入基本一开始就跑不动。
改成批量写入之后，情况完全不同。按 1 秒一批、每批 10000 行来算，事务数从每秒 10000 次降到每秒 1 次，WAL 刷盘从 10000 次降到 1 次，索引更新可以做批内排序后顺序合并，磁盘拿到的是大块顺序写而不是随机小写。同样的硬件，吞吐能上一个台阶，而且延迟更稳定，不会因为偶发的刷盘抖动造成尖刺。
所以高频采集的标准架构是：网关侧先在本地攒批（比如 1 秒或 5 秒一个批次），接收端收到后先落到本地持久化队列（磁盘上的 spool 文件或消息队列），再由入库程序按固定批大小批量灌进时序库。这一层队列有两个作用：一是削峰，断网恢复时的补传洪峰先堆在队列里慢慢消化；二是解耦，数据库重启或做索引重建时，数据不会丢，只是延迟入库，恢复后自动补上。这一层队列必须是持久化的，放在内存里等于把风险从网关搬到了服务器。
批大小怎么定没有标准答案，有一个实用的调法：先按 1 秒的数据量作为批大小起步，观察写入延迟和磁盘利用率；如果磁盘利用率不满而延迟偏高，把批大小调大；如果单批耗时超过采集周期，就拆小或改成时间窗口触发（攒够 N 条或超过 T 毫秒就发，谁先到听谁的）。别让批次无限攒下去，攒批的代价是数据可见延迟。
把上面几节串起来，机房侧接收端服务器的配置优先级应该是：磁盘 > 内存 > 带宽 > CPU。这个顺序跟大多数人的直觉相反，但跟工业数采的实际负载吻合。
工业数采的磁盘负载特征是长时间、不间断的中等强度写入，偶尔叠加补传洪峰。这种负载下容量往往不是问题，写入的稳定性和一致性才是。两个建议：一是用企业级 SSD 或 NVMe，别用消费级 SSD——消费级盘靠 SLC 缓存跑出漂亮的数字，缓存写满之后持续写入速率可能掉到一百兆字节每秒量级，而数采是 24 小时不停写的，缓存根本没机会回收；二是留出至少 30% 的空闲空间，时序库的压缩合并、索引重建、分区整理都需要临时空间，盘写满导致的故障往往不是"写不进去"这么温和，而是整个实例崩溃。
阵列与冗余上，系统盘做 RAID 1，数据盘按容量与可靠性要求做 RAID 10 或多盘 JBOD 加应用层副本。机械盘并不是不能用，但只适合低点位、低频次、且对写入抖动不敏感的冷数据归档，不适合做主接收端。
内存主要花在三个地方：接收端的写入缓冲（应对补传洪峰）、时序库的内存表与热段缓存、操作系统页缓存。经验配比是把最近 7 到 30 天的热数据尽量留在内存里，这样报表查询不用每次都打磁盘。按上面的估算，1000 点、1 秒采样一天 7 GB，7 天热数据就是 50 GB，压缩后在内存里会小很多，配 64 GB 比较从容；5000 点、500 毫秒的场景一天 69 GB，热窗口要收窄到 1 到 3 天，或者干脆依赖磁盘缓存，内存 128 GB 起。
协议解析、点位映射、格式转换都是轻量操作，1000 点规模的接收端 4 到 8 核通常就够。真正吃 CPU 的是三件事：TLS 加解密（大量网关走加密隧道时）、时序库压缩与聚合计算、以及报表侧的复杂查询。如果这三样都不重，把预算从 CPU 挪到磁盘和内存上，收益大得多。判断方法很直接：上线后看负载，如果 CPU 长期低于 20% 而磁盘利用率长期高于 70%，说明配反了。
按稳态带宽选带宽必然踩坑，因为补传时的流量是稳态的数倍。规划时按"稳态 × 5"作为突发峰值来定上行，并且要求网关侧支持补传限速。举个算例：1000 点、1 秒采样稳态 0.4 Mbps，断网一小时后要补 1.8 GB 数据；如果限速到稳态的 5 倍即 2 Mbps，需要约 2 小时追平，这段时间里实时数据还在继续产生，队列会持续增长，所以限速倍数要跟补传窗口一起算，不能拍脑袋。
接收端建议双电源接不同供电回路，双网卡做绑定。机房侧还要确认 UPS 与柴油发电的切换能力，以及机柜的供电上限。工业数采一旦上线就是常年运行，硬件单点故障的代价远高于多花的那部分预算。
车间到机房这一段怎么连，取决于点位规模、厂区数量、数据敏感度和预算，三种主流形态各有适用条件。
加密隧道（公网上的 IPsec / SSL 隧道）。开通快、成本低，适合单厂区、点位规模不大、带宽需求在几兆以内、对抖动不太敏感的场景。缺点是跨运营商链路的质量不可控，晚高峰抖动和丢包会直接影响上报；而且公网出口的 NAT 会话数和带宽上限要提前确认。如果选这条路，网关侧的缓冲能力必须按"最坏断网时长"配足，别指望链路永远稳定。
企业组网（SD-WAN 或多分支组网）。适合有多个厂区、需要统一地址规划、需要按业务分优先级的场景。好处是链路可管可控，能在多条底层链路之间做切换和负载分担，还能给数采流量单独划一条通道，跟办公流量隔离。缺点是部署周期长一些，需要各站点都有可用的上行线路。
点对点互联。单个厂区到单个机房、数据不希望经过公共网络、对稳定性和时延要求最高的场景选这个。稳定性和可控性最好，代价是扩展性弱（每新增一个站点就要新增一条）和成本随距离走。如果你的产线数据涉及工艺配方、良率这类敏感内容，这条路值得考虑。
还有一个几乎所有场景都该配的东西：备份链路。用 4G/5G 做兜底，平时不承担流量，主链路中断时自动切换，恢复后自动切回。成本不高，但能把"断网几小时"变成"断网几十秒"。形态选完之后还有一件事要定：机房侧的接收端到底放在哪个机房、用哪种机型，这就回到前面那张估算表上了。
前面讲的所有设计，不上线演练等于没做。下面五项建议在验收阶段全部跑一遍，每一项都有明确的判定标准，跑不过就不要签字。
拔掉网关的上行网线，分别测 5 分钟、1 小时、4 小时三档。判定标准：断网期间网关本地缓冲持续增长且不丢、链路恢复后自动重连、重连时间不超过既定阈值、补传过程中实时数据不中断。同时记录缓冲水位曲线，验证"最长断网时长 × 每秒字节数"这个算式跟实际是否吻合。
在演练一的基础上观察接收端：磁盘利用率、写入延迟、队列长度、CPU 使用率，以及有没有重复数据。判定标准：补传期间接收端磁盘利用率不超过 80%、实时数据的入库延迟不显著上升、补传完成后数据条数与时间窗口完整、没有重复记录。如果补传把接收端打挂了，说明限速策略没做好，回去调。
让网关离线 72 小时，期间不接 NTP，结束后与标准时间对比，记录漂移量。再模拟一次"漂移状态下的补传"，验证接收端能否正确识别迟到数据、能否触发对应时间窗口的重算。判定标准：漂移量在业务可接受范围内（通常秒级），且补传数据落到正确的时段。
在测试环境把数据盘写到 85%、95%、100%，观察告警是否触发、接收端是否优雅降级（拒绝新写入并正确返回错误给网关，让网关继续缓冲）而不是崩溃。判定标准：85% 有告警、95% 有严重告警、写满时网关侧能感知并把数据留在本地而不是静默丢弃。
分别在补传进行中、队列积压时，用 kill -9 杀掉接收进程，以及直接重启服务器。判定标准：队列中的持久化数据不丢、重启后能从断点继续消费、不出现重复入库、网关侧能感知接收端不可用并继续本地缓冲。这一项最容易暴露问题，因为很多接收端的队列默认是内存态的。
前面算出来的四个数——每秒数据点、上行带宽、每日落库量、保留一年的磁盘容量——就是给机房侧提需求的输入。把它们写成一张需求单，比"要一台好点的服务器"有用得多：
磁盘需求：保留周期 × 每日落库量 × 1.2，并且明确要求企业级 SSD 或 NVMe、要求写入带宽而非只是容量指标、要求留出 30% 空闲空间。很多采购单只写容量不写介质类型，交付的时候拿到一块大容量机械盘，跑三个月就开始抖。
内存需求：按热数据窗口反推，同时给接收端队列留独立的缓冲空间。队列缓冲不需要很大，能扛住十分钟的补传峰值就够，但一定要有。
带宽需求：稳态值加突发值两个数都要写。稳态决定日常费用，突发决定补传能不能追平。只写稳态，机房侧给的端口可能在补传时成为瓶颈。
冗余需求：双电源、双网卡绑定、可用的 IPMI 或远程管理口。远程管理口在工业场景里的价值被严重低估——厂区到机房往往没有驻场人员，半夜接收端卡死的时候，能远程重启比什么都强。
拿着这张需求单去对机房侧的机型与存储档位，比选就会变得很具体。一万网络这类深耕 IDC 19 年（成立于 2007 年）的服务商，其机房侧的服务器与存储配置档位可以作为接收端选型的对照参考之一，具体机型、带宽形态与价格需实时询价，建议按自己的估算结果去核，而不是按套餐默认值下单。
取决于两件事：缓冲介质的可用容量和每秒写入字节数。算法是"缓冲容量 ÷ 每秒字节数"。按本文的估算口径，1000 点、1 秒采样约 52 KB/s，一个 8 GB 的持久化缓冲理论上能撑约 43 小时；5000 点、500 毫秒采样约 520 KB/s，同样 8 GB 只够约 4 小时。但要注意"断电"和"断网"是两回事——断电时网关根本不采集，缓冲里的内容只要介质不掉电就不会丢，真正要担心的是掉电瞬间的页刷新，所以带掉电保护电路的网关比容量多几个 G 更有意义。
会，如果不限速。断网一天意味着要补 24 小时的量，补传速率通常是稳态的数倍，接收端会同时承受实时写入和补传写入两股压力。解决办法是网关侧限速加接收端节流：网关按约定的倍数（比如稳态的 3 到 5 倍）慢慢补，接收端按自己的写入能力动态调整接收窗口。补传窗口要提前算清楚——补 24 小时的数据，用 5 倍速率也需要接近 5 小时，这段时间队列是净增长的，如果增长量超过接收端的队列容量，就要考虑分时段补传或者临时提升接收端的写入能力。
最稳妥的做法是在数据模型层做幂等：把（点位 ID + 采集时间戳）设为唯一键，重复写入时执行覆盖而不是插入。时序库通常天然支持这种语义，同一 series、同一时间戳写入新值就是覆盖。关系库则要用唯一索引加 ON CONFLICT DO UPDATE。还有一处要考虑：值相同但确实是两次采样的情况——如果两个不同的采样点恰好同时间戳同值，去重会误伤，这就是为什么时间戳精度要足够（毫秒级），并且网关要保证同一批数据的序列号连续可校验。
联网状态下建议 5 到 15 分钟同步一次 NTP，并在偏差超过阈值时告警。离线场景没有固定答案，取决于 RTC 的精度：可以先做一次 72 小时离线漂移测试，测出每天的漂移量，然后按"业务可接受的最大时间误差 ÷ 每天漂移量"反推最长允许离线时长，超过这个时长就必须在重新联网后先校时再补传。带温度补偿的 RTC 模块在这个问题上性价比很高，值得在采购时明确要求。
十倍的关系，而且是线性传导到带宽、写入量和存储三个维度。1000 个点，1 秒采样是 1000 点/秒，100 毫秒采样就是 10000 点/秒，存储从每天 7 GB 变成 70 GB，保留一年从 3 TB 变成 30 TB。所以采样周期的选择应该是业务需求驱动的：温度、液位这类慢变量 1 到 10 秒足够；压力、流量可以 1 秒；振动、电流、高速计数这类快变量才需要 100 毫秒甚至更高。混在一起统一按最高频率采，是工业数采里最常见的浪费。
时序库存原始采样点和降采样聚合结果，负责高并发写入、按时间范围扫描、降采样和生命周期管理；关系库存主数据：点位表、设备台账、产线层级、工单与批次信息、用户权限。两边用点位 ID 关联。不要把点位元数据也塞进时序库，时序库的标签列是为低基数维度设计的，放高基数的文本字段会拖垮索引。反过来也别用关系库存原始采样点，写入量一大就会遇到锁竞争和 vacuum 压力。
看两个指标：稳态上行带宽和链路稳定性。按本文的估算方法，100 点、1 秒采样需要约 0.04 Mbps，4G 上行通常够；1000 点、1 秒采样约 0.4 Mbps，加上协议开销和实际信号波动，勉强够但不宽裕；5000 点、500 毫秒采样约 4 Mbps，4G 基本扛不住，而且补传时的峰值更吃力。除了带宽，还要看延迟抖动和断流频率——4G 在车间这种电磁环境复杂的地方，信号衰减和基站切换都可能造成秒级到分钟级的中断。如果只能用 4G，建议把它当作备份链路，或者干脆降低上报频率、加大本地聚合力度，把上报量压到链路能承受的范围。
回到开头那家线束厂。他们后来做的事其实不复杂：把网关的内存队列换成带掉电保护的持久化缓冲、把缓冲深度从"条数"改成"时长"、给网关和服务器接同一个厂区 NTP 源、在接收端前面加了一层持久化队列并做了批量入库和补传限速、上线前把五项演练全跑了一遍。交换机后来重启过几次，报表再没缺过。
这套动作里没有一步是"换更强的 CPU"。工业数采场景里服务器的瓶颈从来不是算力，而是链路可靠性、时钟一致性、写入连续性这三件事。选型的时候，按点位规模和采样周期反推写入量和带宽，比按核数挑机器靠谱得多——前者能被验证，后者只是感觉。如果你的产线正在做数采改造，先把点表拉出来，把每秒数据点、上行带宽、每日落库量、一年保留容量这四个数算清楚，拿着这四个数去谈网关和服务器，你会发现讨论效率完全不一样。
本文给出的 40 字节/点、1.3 倍封装系数、2 倍落库冗余、20% 运维余量，全部是便于快速核算的估算口径，不是实测数据，也不一定适用于你的现场。真实的点表结构、编码方式、时序库的压缩算法、死区过滤的命中率，都会让实际数字偏离这些估算，偏离一倍以上是常有的事。
这套方法的价值在于提供一个可校验的起点：先按它算出一个量级，再用现场的真实数据去修正系数，修正过一次的系数就可以用在你所有的后续项目上。真正需要现场确认而不能靠估算的有三样：网关在满负荷下的实际缓冲时长、RTC 的实际漂移量、接收端在批量写入下的实际 IOPS。这三样拿不到实测数据，就不要做最终选型。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
