硬盘
负载均衡和缓存这些工作，你就按照常规去做就行。不过在做之前，我在业务层面有个问题没想通，怎么感觉题目里对这个项目的介绍好像缺了些关键信息？首先，哪些设备必须按照固定的时间来上传数据？为什么不能在状态改变的时候才上传？除非设备状态改变的频率远高于上传的时间间隔，就像环境检测传感器那样，每几个毫秒甚至更短时间就改变一次状态，这种情况下采用固定时间采样或者汇总上传确实有助于减轻负担。否则的话，状态改变触发上传看起来更科学啊。但是如果是这种高频状态转换的情况，还采用固定时间上传的方式，那就和客户要求的实时查询有冲突了。这种定时采样不符合严格意义上的实时数据，就像示波器这个不太恰当的例子一样，这就有点奇怪了。要么让设备实现状态改变就上传，直接存入数据库，然后只处理数据库相关的问题，这样的话，别说是实时查询了，时间回溯都没问题；要么就定好时间段和有效载荷，直接生成需要展示的内容，展示完就完事了，毕竟这种纯粹为了给客户展示而加工过的数据，就算存入数据库后面也分析不出什么来。可按照题目所说的情况，这两种方式都不沾边啊。所以，最好还是明确一下客户所说的实时查询到底真正的需求是什么。另外，如果是固定时间上传，1 - 10K的数据量也不算小了，会不会出现集中上传时带宽拥塞的问题？我觉得这是很有可能出现的风险。再来说说所谓的实时查询，是弄个大屏不断刷新显示，还是那种主动点击查询按钮的方式？如果是弄个大屏不断刷新，那还不如和数据库解耦，不从中拿数据，直接抓取设备上传的数据来显示，这样会快很多，不算网络延迟的话，基本能保证设备上传后准实时显示。要是这样还不好弄的话，就把设备分类汇总，部署几个边缘计算节点，让计算节点生成展示数据放到大屏上，速度也慢不了多少。如果是点击查询那种方式，那就得和数据库打交道了，说白了就是写入和读取这两端会存在瓶颈。这么多的数据能不能确保写入数据库？题目对规模的描述比较模糊，很难准确估计。不过除非还在用机械
硬盘直接写入，基本不太可能在
硬盘写入速度上出现瓶颈。退一步说，就算来不及写入，在前面放个队列，后面放个缓存，也不至于丢数据，如果还丢数据，那就是后端代码的问题了，把程序员祭天就能解决（当然是开玩笑的啦）。第二个瓶颈在于读取，尤其是锁的问题，这个一两句话真说不清楚，从数据库到设计再到代码都可能存在问题，程序员已经祭天过了（还是玩笑话），那就烧点黄纸给他，让他把产品经理和数据库管理员一起带走，世界就清净了。
