Influxdb

背景 2017 年前后，我在大连 R 公司负责 R 平台协议解析层的开发和维护。R 平台是一套车联网平台，部署在 H 云上，用来接收和处理车载设备实时上报的数据。 协议解析层有十五个以上的服务，每个服务至少两个节点，负责解析车载设备上报的自定义 TCP 协议，网络通信与连接处理底层由 Netty 实现。平台共有 300 多台虚拟机，单个服务的规格通常不会拉很高，G4 所在的虚拟机配置是 2 CPU、4 GB 内存。 其中 G4 是协议解析层数据量最大的服务，负责解析行车数据，单条消息包含约两百个字段，涵盖车速、转速、门窗锁状态、发动机参数、各类液体温度、油量等实时车况信息。正常 QPS 约 700 条/秒，峰值超过 1000 条/秒，四个节点加起来总 QPS 在 5000 左右。 解析完成后，G4 把数据写入 Redis（实时数据）和 MySQL（行车历史数据，水平分片成 1024 个库），另外还有一些平台内部的 API 调用。MySQL 访问层是在 JDBI 基础上封装了一层。 协议解析层的数据来自上游接入层，接入层向协议解析层推送数据，同时用 RabbitMQ 做消息队列缓冲。 装车增长与早期告警 R 平台接入的设备数量持续增长，每个月有几千台新设备安装到实车上。随着在线行驶车辆增多，G4 的数据量也跟着涨。 大规模故障之前，G4 就开始在早高峰和晚高峰偶发内存告警，高峰过去后十几分钟会自行恢复。当时不清楚具体原因，尝试过把业务线程数从默认值增加到 16，改完之后等服务低峰期重启，观察下一次高峰是否有改善。效果不明确，可能有一定缓解，也可能影响有限，之后就转向其他方向排查，线程数就维持在 16 没有再改。 大规模 OOM 装车量继续增加，某天 G4 出现了大规模 OOM。现象是四个节点滚动离线：一个节点 OOM 重启，剩余节点压力上涨，接着下一个离线，重启后很快再 OOM，如此循环。 节点重启之后撑不了太久，因为上游 RabbitMQ 里已经积压了大量数据，积压时间估计有一两个小时。一个节点恢复，积压数据涌入，Netty 堆外内存里挤满了等待处理的业务数据，内存很快再次撑满。一个节点离线，剩余三个节点分摊的流量更大，内存涨得更快，形成连锁反应。节点之间的 OOM 间隔只有几分钟。 ...