另外给点建议，websocket 在客户端通知这块没法在负载均衡环境下使用，因为本身是长链接，如果以后后端服务横向扩展，这里就会出问题。一般物联网的解决方式是 websocket 连 mqtt ，后端订阅 mqtt 发送通知。不过你这个场景只是传感器发送消息到服务器单向通信，应该没这个问题，所以其实我觉得也挺怪的，为啥传感器和服务器走的是 websocket ，而不是走 mqtt ？如果走 mqtt ，你们应该就没有目前这个问题了。

@StoneHuLu 内存管不够😂

@autumnhlf01 #11 云服务器的话内存不是挺便宜的吗？我觉得你们目前对于“数据量大导致数据库有压力”、“redis 内存不够”、“redis 数据大查询慢”，都是主观臆测，有做过具体实验测试过吗

@autumnhlf01 多大量啊，批量写 mysql 每秒写入也不小，想那么多干嘛每秒合并下写完了，如果数据量大肯定要换 kafka 加其他时序或者列存数据库，折腾什么 redis mq 的纯属多余

@StoneHuLu 项目以前就因为内存原因挂掉过，次数不多就是了

原始数据不必存 MySQL ，可以按设备和日期存文件，可一次性分好类也可先顺序写入再择时归档。 当日数据存 redis ，一两天的量不至于大到存不下。按照时间粒度做聚合汇总，存入 MySQL 。 统一查询接口，查询条件必须带时间，由接口负责去不同的地方取数据拼装组合，如果取明细原始数据，那就读文件获取。 以上方案经过日请求 100 亿次的项目检验。 MySQL 写入性能其实也不低，高配机器每秒插入 10 万条也没啥压力，分库到 10 台就是 100 万/s 的性能。

@sagaxu 我觉得你的这种方案挺不错

几十秒一组也还好。真的扛不住可以先放缓存里，然后定时刷入。MySQL 批量插入的时候速度会更快点。还可以考虑优化硬件，用 IO 性能好点的磁盘。最大的问题其实是后续取数据，量非常大的时候，复杂 SQL 会很慢，之前设计的时候除了 MySQL 存一份，还会同步到类似 ClickHouse 之类的 OLAP 数据库。 而且表太大，数据库维护也麻烦，导致出现问题的时候需要很长的停机时间。

直接存数据库的压力在哪里呢？我现在也在做差不多的项目，数据是通过 MQTT 传的。

是数据库压力真的大还是仅仅你觉得大？