从分钟到毫秒：构建“城市生命线”的实时数字心脏-ThingsPanel物联网平台

一、背景：物联网平台面临的性能挑战

在城市生命线监测系统中，物联网平台需要处理海量设备的实时状态上报。随着接入设备从千级向十万级扩展，传统的关系型数据库方案暴露出明显的性能瓶颈。

1.1 典型场景的技术挑战

城市生命线监测系统涉及燃气、供水、排水、桥梁等关键基础设施，具有以下特点：

• 数万个监测点需要持续上报数据
• 上报频率从秒级到亚秒级不等
• 设备往往分多次上报不同维度的指标
• 需要秒级响应关键告警

1.2 原有架构问题

ThingsPanel早期版本使用 PostgreSQL（TimescaleDB）存储设备当前状态，在高并发场景下观察到：

写入性能瓶颈

• UPDATE 操作的行锁竞争严重
• 高频更新导致数据库连接池压力大
• 磁盘 I/O 成为主要限制因素

数据更新复杂度

• 设备分次上报不同指标（如先报压力，后报流量）
• 每次更新需要查询现有数据再合并
• 局部更新操作开销较大

响应延迟累积

• 毫秒级的单次延迟在高并发下累积
• 告警响应出现"长尾效应"
• 影响实时监控效果

二、ThingsPanel 的优化方案：Redis Hash 设备影子

2.1 设计思路

ThingsPanel将设备当前状态（Device Shadow）从磁盘数据库迁移至 Redis 内存存储，核心设计包括：

存储结构选择

• 采用 Redis Hash 结构
• Key 格式：device:shadow:{device_id}
• Hash 字段对应设备各项属性

更新策略

• 利用 HSET 的字段级更新特性
• 支持分次上报的自动合并
• 无需预先查询和手动合并逻辑

持久化策略

• 不设置过期时间，保留设备最后已知状态
• 定期持久化到 TDengine 时序数据库用于历史分析
• 系统重启时从持久化存储恢复

2.2 技术实现要点

数据类型支持

• ounter(line
• ounter(line
• ounter(line

简单类型：数值、布尔值、字符串对象类型：JSON 对象（如泵站状态）数组类型：JSON 数组（如振动序列数据）

并发控制

• 无需应用层加锁
• Redis 单线程模型保证原子性
• 通过连接池管理并发请求

容错设计

• Redis 主从复制保证高可用
• 持久化数据作为冷备份
• 支持降级到数据库存储

三、实际应用场景

3.1 燃气安全监测

设备类型：膜式燃气表、压力监测终端、甲烷探测器

数据特点：

• pressure：实时压力值，需秒级更新
• methane_conc：甲烷浓度
• battery_voltage：设备电量
• status：阀门状态

优化效果：

• 压力异常告警延迟从 500ms 降至 50ms 以内
• 支持 3 万个监测点同时上报
• 数据库连接数从 800 降至 50

3.2 排水内涝监测

设备类型：电子水尺、超声波水位计、流量计

数据特点：

• water_level：积水高度
• flow_rate：管道流速
• pump_info：泵站状态对象 {"power": 220, "working": true}

优化效果：

• 暴雨期间上报频率增加 10 倍仍保持稳定
• 水位监控大屏刷新延迟降至毫秒级
• 系统 CPU 使用率从 85% 降至 30%

3.3 桥梁结构监测

设备类型：静力水准仪、倾角仪、加速度计

数据特点：

• displacement：沉降位移（毫米级）
• angle：倾斜角度对象 {"x": 0.02, "y": 0.01}
• vibration：振动频率数组 [1.2, 1.5, 1.1, ...]

优化效果：

• 支持 100Hz 高频采样数据实时更新
• 复杂 JSON 对象直接存取，无需序列化开销
• 历史振动波形查询从 TDengine 获取，当前状态从 Redis 获取

四、性能对比数据

基于 ThingsPanel 测试环境（8 核 16G，Redis 6.x）：

4.1 写入性能

4.2 查询性能

4.3 系统稳定性

压力测试场景：1 万设备，每秒 3 次上报（共 3 万 QPS）

• PostgreSQL 方案：连接池耗尽，系统频繁告警
• Redis 方案：稳定运行，延迟 P99 保持 10ms 以内

五、ThingsPanel 平台的整体架构

优化后的 ThingsPanel 采用分层存储策略：

实时层（Redis）

• 存储设备当前状态
• 支持毫秒级查询和更新
• 用于实时监控和告警

时序层（TDengine）

• 存储历史数据
• 支持趋势分析和统计查询
• 高压缩比降低存储成本

协同机制

• 每次状态更新同时写入 Redis 和 TDengine
• Redis 故障时降级到 TDengine
• 定期从 Redis 同步快照到持久化存储

六、实施建议

6.1 适用场景

该方案特别适合以下场景：

• 设备数量 > 1 万
• 上报频率 > 1 次/秒
• 需要毫秒级状态查询
• 设备属性频繁变化
• 有复杂数据类型需求

6.2 部署要点

Redis 配置

• 建议内存配置为设备数量 × 5KB（估算值）
• 启用 RDB 持久化作为冷备份
• 配置主从复制保证高可用

监控指标

• Redis 内存使用率
• 命令执行延迟 P99
• 连接数和拒绝连接数
• 持久化同步延迟

6.3 迁移步骤

1. 在测试环境验证 Redis 方案
2. 实现 PostgreSQL 和 Redis 双写
3. 逐步切换读流量到 Redis
4. 验证一段时间后停止 PostgreSQL 写入
5. 保留 PostgreSQL 历史数据用于分析

七、总结

ThingsPanel通过引入 Redis Hash 作为设备影子存储，解决了物联网平台在大规模设备接入场景下的性能瓶颈。该方案的核心价值在于：

1. 性能提升：写入延迟降低 15 倍，吞吐量提升 16 倍
2. 架构简化：利用 Redis 原生特性，减少复杂的合并逻辑
3. 成本优化：降低数据库压力，节省硬件投入
4. 可靠性增强：分层存储策略兼顾实时性和数据安全

该方案已在多个城市生命线监测项目中应用，支撑了数万设备的稳定运行。