IoT 数据汇聚节点的配置

IoT 场景里，服务器的压力通常不在数据量，而在连接数。十万台设备每天各上报一条消息，流量还不如一场直播，但十万条并发连接能把没调优的机器直接压垮。 海量连接的技术账 每条 TCP 连接在 Linux 上要消耗文件句柄和内存，默认配置下单进程的连接数上限远低于业务需求。汇聚节点要做的系统级调整：调大文件句柄上限，ulimit 和 systemd 的 LimitNOFILE 一起改；内核参数里放宽连接跟踪表 nf_conntrack 的上限；单台 4 核 8G 的机器调优后承载几万条长连接是常规水平。设备端的心跳间隔别设太短，5 分钟一次和 30 秒一次相比，服务端的负载能差一个量级，在允许范围内取长间隔。 消息队列是缓冲层 设备数据不能直连数据库：设备上报是脉冲式的，整点、定时报文会让写入量瞬间翻几十倍。中间放一层消息队列，接入服务只管收，消费进程按数据库的写入能力匀速入库，队列天然削峰。队列积压量要上监控，持续增长说明消费能力不足，及时扩消费者，这个指标比 CPU 占用率更能预警故障。 协议与数据分层 接入协议按设备能力选：资源充足的设备走 MQTT 这类轻量发布订阅协议，极简设备可以用 UDP 上报加服务端确认。数据分两层存：实时状态放内存或缓存，历史数据进时序数据库，按时间分区定期降采样，一年以上的明细转压缩归档。 配置建议 起步 4 核 8G 加 SSD；连接数过五万或写入持续吃紧时，把接入层和存储层拆开分别扩容。顺云的高防云服务器 S4-8G 适合作为汇聚主机，内存升级款的定位扛得住连接表开销，公网设备的入口机也确实需要基础的恶意流量防御。 IoT 后端的扩容顺序是先调优、再拆层、最后加机器，顺序反了就是白花钱。