简介这份PDF文档面向风电行业软件开发人员、系统架构师及新能源集控平台设计者系统梳理了智能风电场系统项目的软件功能需求可作为需求分析、方案设计与技术选型的参考蓝本。资源包共1个PDF文件大小约12.77MB内容以图文表格形式组织便于按模块查阅。文档围绕远程集中监视及分析系统展开涵盖实时数据采集、数据服务、断点续传与通讯协议管理等底层能力并逐项拆解生产运行监视、发电场站监视、单台风机监视、升压站监视、功率预测监视与测风塔监视六大应用场景涉及风机矩阵展示、报警事件列表、设备状态台数统计、功率曲线叠加与电网格式数据导出等具体功能点。目前已有178人学习适合需要理解风电场集控SIS平台功能边界、撰写需求文档或规划监控系统模块的读者参考借鉴。1. 智能风电场系统项目从一份 PDF 需求到能跑起来的监控原型如果你手里也有一份叫「智能风电场系统项目.pdf」的文件大概率它不是一篇论文而是一份需求说明、课程设计任务书或者甲方给的方案框架。它真正要解决的问题很具体把分散在几十台风机上的风速、转速、功率、温度这些测点收上来存下来再在屏幕上实时画出来顺便判断哪台机器可能要出问题。这件事听起来像工业互联网的常规操作但真动手就会发现风机数据的时间对齐、断点续传、告警抖动这三件事每一件都能让人加班到凌晨。这篇笔记不假装见过那份 PDF 的正文只按这个标题在行业里最常见的落地路径把选型、采集、存储、可视化、排错一条线讲清楚。适合做能源方向上位机、物联网平台、或者要交一个能演示的毕业设计的工程师新手能照着搭出最小系统熟手能对照检查自己的参数边界。2. 先定架构智能风电场系统为什么很少一上来就上微服务2.1 从 PDF 里的功能条目反推技术栈一份典型的智能风电场系统需求拆开看无非四块数据采集、数据存储、实时监控、统计分析。很多人的第一反应是 Spring Cloud 加 Kafka 加 Flink 加 ClickHouse一套下来光环境就能搭两天。但风电场现场的现实是风机主控 PLC 走 Modbus TCP 或 OPC UA单台风机测点通常在 50 到 200 个之间整场 20 台风机满打满算一万个测点采样周期 1 秒到 10 秒可调。这个量级用单体应用加时序数据库完全扛得住上微服务反而让部署和排错变成玄学。我一般会推荐这样的分层采集层用 Python 或 Go 写一个常驻进程按风机 IP 轮询消息层用 Redis 的 Stream 或者直接写本地磁盘队列做缓冲存储层用 TDengine 或 InfluxDB 存时序数据MySQL 存风机台账和告警记录展示层用 Grafana 或者自己写一个 Vue 页面调 WebSocket。这套组合在一台 8 核 16G 的工控机上就能跑现场断电重启后恢复也快。选型理由要落到参数上TDengine 建库时KEEP设 365 天DAYS设 10CACHEMODEL开both这样最近数据和历史数据查询都不会太慢。InfluxDB 则要注意retention policy别设成 autogen 无限保留风机数据一天一万测点乘 86400 秒不加限制磁盘三个月就满。2.2 最小可运行拓扑与端口规划在动手写代码之前先把网络拓扑在纸上画一遍。风电场通常分管理大区和生产大区中间有隔离装置。如果只是做演示或课程设计可以简化为一个局域网一台采集服务器双网卡一张网卡连风机网段一张网卡连办公网段。端口规划上Modbus TCP 默认 502OPC UA 默认 4840TDengine 默认 6041Grafana 默认 3000。这些端口在现场经常被防火墙拦提前找网络组开白名单比写完代码再排查快得多。下面是一个用 Python 做 Modbus TCP 采集的最小示例假设风机 PLC 的寄存器地址已经拿到风速在 40001有功功率在 40003都是 16 位无符号整数需要除以 10 得到实际值。from pymodbus.client import ModbusTcpClient import time import json # 风机 PLC 的 IP 和端口现场按实际改 PLC_IP 192.168.1.101 PLC_PORT 502 client ModbusTcpClient(PLC_IP, portPLC_PORT) client.connect() def read_wind_turbine(): # 读保持寄存器起始地址 0 对应 40001数量 4 个 rr client.read_holding_registers(address0, count4, slave1) if rr.isError(): print(读取失败检查链路) return None wind_speed rr.registers[0] / 10.0 # 风速单位 m/s active_power rr.registers[2] / 10.0 # 有功功率单位 kW return {wind_speed: wind_speed, active_power: active_power, ts: int(time.time())} while True: data read_wind_turbine() if data: # 这里先打印实际项目写入 Redis Stream 或直接入库 print(json.dumps(data)) time.sleep(1) # 采样周期 1 秒现场可放宽到 5 秒这段代码的逻辑很直白建立 TCP 连接按寄存器地址读四个值取前两个做缩放。参数说明上address0对应 Modbus 协议里的 40001如果 PDF 里给的是 30001 开头的输入寄存器要换成read_input_registers。slave1是风机从站号多台风机串联时这个值必须区分开。time.sleep(1)是采样间隔现场如果测点超过 100 个建议改成 5 秒否则 PLC 的 TCP 连接数会被占满。注意Modbus TCP 没有断线重连机制client.connect()返回 True 不代表后续读取一定成功。生产环境要在循环里加异常捕获失败后client.close()再重新连接否则程序会卡死在读操作上。3. 数据落库与实时告警智能风电场系统的存储表怎么建才不后悔3.1 时序库建表与写入参数数据采上来之后第一件事是决定存哪里。用 MySQL 存时序数据不是不行但一天一千万行之后SELECT最近一小时的数据都要几秒。TDengine 的超级表模型很适合这个场景一张超级表按风机编号建子表每个测点一列。建表语句如下。-- 创建超级表采集周期 1 秒保留 365 天 CREATE STABLE wind_turbine ( ts TIMESTAMP, wind_speed FLOAT, active_power FLOAT, rotor_speed FLOAT, gearbox_temp FLOAT ) TAGS ( turbine_id BINARY(16), farm_id BINARY(16) ); -- 为 1 号风机建子表 CREATE TABLE turbine_001 USING wind_turbine TAGS (WT001, FARM_A);参数上TIMESTAMP默认毫秒精度如果 PDF 要求微秒建库时指定PRECISION us。FLOAT占 4 字节风机测点用FLOAT足够别用DOUBLE浪费空间。TAGS里的turbine_id是标签查询时按标签过滤比按列过滤快一个数量级。写入时用参数绑定不要拼 SQL 字符串否则测点一多解析开销很大。写入的 Python 示例import taosrest conn taosrest.connect(urlhttp://localhost:6041, tokenyour_token) cursor conn.cursor() # 批量写入一次 100 条减少网络往返 sql INSERT INTO turbine_001 VALUES (%s, %s, %s, %s, %s) data [(1690000000000, 5.2, 1200.5, 15.3, 45.2), (1690000001000, 5.3, 1210.0, 15.4, 45.3)] cursor.executemany(sql, data) conn.commit()executemany比单条execute快很多批量大小控制在 100 到 500 之间太大反而容易超时。taosrest走 HTTP 6041 端口如果现场对性能要求高换taos原生连接走 6030 端口。3.2 告警规则与防抖动处理智能风电场系统里告警是甲方最看重的功能也是最容易翻车的地方。齿轮箱温度超过 80 度告警这个规则写起来一行代码但风机在夏天满发时温度本来就在 75 到 85 之间波动如果直接if temp 80: alarm()运维人员的手机一天能收几百条短信最后的结果是把告警关掉。常见的做法是加迟滞和持续时间判断温度超过 80 度且持续 30 秒才触发触发后要等温度降到 75 度以下才恢复。用 Redis 的过期键或者内存状态机都能实现。下面是一个简化的状态机逻辑。import time class AlarmState: def __init__(self, high80.0, low75.0, duration30): self.high high self.low low self.duration duration self.trigger_time None self.active False def update(self, temp): now time.time() if not self.active: if temp self.high: if self.trigger_time is None: self.trigger_time now elif now - self.trigger_time self.duration: self.active True self.trigger_time None return ALARM_ON else: self.trigger_time None else: if temp self.low: self.active False return ALARM_OFF return Nonehigh和low之间的差值叫死区一般取量程的 5% 到 10%。duration根据测点变化速率定温度这种慢变量 30 秒合理振动这种快变量可以缩到 5 秒。这段逻辑要放在采集进程里不要放在数据库的定时任务里否则采样间隔和判断间隔对不上会出现漏报。提示告警记录一定要单独存一张表包含触发时间、恢复时间、测点值、规则编号。事后追查时这张表比时序数据更有用。4. 避坑与排查智能风电场系统上线前必须过的五道坎4.1 风机数据时间戳对不齐现象Grafana 上画出来的风速和功率曲线错位功率变化总是比风速晚几秒。原因采集程序用本地时间打时间戳但不同风机的 PLC 响应延迟不一样有的 50 毫秒有的 500 毫秒批量写入时顺序乱了。解决在采集端统一用time.time()打时间戳不要用 PLC 返回的时间如果 PLC 支持读它的系统时间做校准入库时按时间戳排序TDengine 会自动处理乱序数据但查询时加ORDER BY ts更稳妥。4.2 Modbus 读取返回 Exception Code现象程序日志里频繁出现Exception Response (131, 2)。原因131 是功能码 3 加 1282 表示非法数据地址。PDF 里给的寄存器地址可能是从 1 开始计数的而代码里从 0 开始。解决确认地址偏移40001 对应代码里的 030001 对应输入寄存器且代码里也要从 0 开始。如果还不行用 Modbus Poll 工具先手动读一次确认地址和从站号。4.3 时序数据库磁盘写满现象系统运行两周后写入变慢最后报错。原因TDengine 默认KEEP是 3650 天数据文件一直不删。解决建库时显式指定KEEP 365并设置DAYS 10让数据按天分片。同时加一个定时任务每天检查磁盘使用率超过 80% 就清理临时文件或扩容。4.4 告警风暴导致短信通道被封现象大风天过后运维人员收到上千条告警短信运营商把短信接口限流了。原因没有做告警合并和抑制。解决同一台风机同一类告警在 5 分钟内只发一次如果整场多台风机同时告警合并成一条汇总消息。这个逻辑可以在告警服务里加一个 Redis 的SETNX带过期时间来实现。4.5 前端 WebSocket 断连后数据不更新现象监控大屏开着过一段时间数字不动了刷新页面才恢复。原因WebSocket 没有心跳中间的网络设备把空闲连接断了。解决前端每 30 秒发一个 ping后端回 pong断连后前端自动重连重连时带上最后一条数据的时间戳后端补发断连期间的数据。这个补发逻辑用 TDengine 的INTERVAL查询很容易实现。5. 从能跑到好用智能风电场系统的数据补传与压测技巧5.1 断网续传的本地队列设计风电场现场网络抖动是常态采集程序不能因为写库失败就把数据丢了。我一般会在采集和入库之间加一个本地磁盘队列用 SQLite 或者文件追加的方式。采集线程只管往队列里写入库线程从队列里读读一条删一条。网络恢复后入库线程自动把积压的数据补上。SQLite 的WAL模式在这种场景下很稳写入不会阻塞读取。import sqlite3 # 本地队列WAL 模式提高并发 conn sqlite3.connect(buffer.db) conn.execute(PRAGMA journal_modeWAL) conn.execute(CREATE TABLE IF NOT EXISTS queue (id INTEGER PRIMARY KEY, payload TEXT)) def enqueue(payload): conn.execute(INSERT INTO queue (payload) VALUES (?), (payload,)) conn.commit() def dequeue(): row conn.execute(SELECT id, payload FROM queue ORDER BY id LIMIT 1).fetchone() if row: conn.execute(DELETE FROM queue WHERE id?, (row[0],)) conn.commit() return row[1] return NoneWAL模式让写和读可以同时进行ORDER BY id保证先进先出。队列文件要放在 SSD 上机械硬盘在频繁小写入时延迟很高。队列长度超过 10 万条时报警说明后端入库出了问题。5.2 用模拟数据做一次压力测试系统上线前最好用模拟数据压一遍。写一个脚本模拟 20 台风机、每台 100 个测点、1 秒采集一次连续跑 1 小时看采集进程的内存和 CPU、数据库的写入延迟、前端页面的刷新帧率。压测时把采样周期改成 100 毫秒相当于 10 倍压力如果 10 倍压力下系统不崩现场 1 秒周期就稳了。压测中重点看三个指标采集进程的常驻内存是否持续增长内存泄漏、数据库的INSERT耗时是否稳定在 10 毫秒以内、WebSocket 推送延迟是否小于 2 秒。任何一个不达标先解决再上线。5.3 一个我踩过的坑别在采集进程里做复杂计算早期版本我把功率曲线拟合、振动频谱分析都放在采集进程里结果采样周期一波动计算任务把采集线程堵死了。后来改成采集进程只做读取和入队计算任务单独起一个消费者进程从队列里拿数据算。这个拆分让采集的稳定性提升了一个档次。记住一句话采集进程越薄越稳计算再重也别堵在采集上。希望帮到你。本文还有配套的精品资源点击获取
智能风电场系统从需求到原型：数据采集、存储与告警实战
简介这份PDF文档面向风电行业软件开发人员、系统架构师及新能源集控平台设计者系统梳理了智能风电场系统项目的软件功能需求可作为需求分析、方案设计与技术选型的参考蓝本。资源包共1个PDF文件大小约12.77MB内容以图文表格形式组织便于按模块查阅。文档围绕远程集中监视及分析系统展开涵盖实时数据采集、数据服务、断点续传与通讯协议管理等底层能力并逐项拆解生产运行监视、发电场站监视、单台风机监视、升压站监视、功率预测监视与测风塔监视六大应用场景涉及风机矩阵展示、报警事件列表、设备状态台数统计、功率曲线叠加与电网格式数据导出等具体功能点。目前已有178人学习适合需要理解风电场集控SIS平台功能边界、撰写需求文档或规划监控系统模块的读者参考借鉴。1. 智能风电场系统项目从一份 PDF 需求到能跑起来的监控原型如果你手里也有一份叫「智能风电场系统项目.pdf」的文件大概率它不是一篇论文而是一份需求说明、课程设计任务书或者甲方给的方案框架。它真正要解决的问题很具体把分散在几十台风机上的风速、转速、功率、温度这些测点收上来存下来再在屏幕上实时画出来顺便判断哪台机器可能要出问题。这件事听起来像工业互联网的常规操作但真动手就会发现风机数据的时间对齐、断点续传、告警抖动这三件事每一件都能让人加班到凌晨。这篇笔记不假装见过那份 PDF 的正文只按这个标题在行业里最常见的落地路径把选型、采集、存储、可视化、排错一条线讲清楚。适合做能源方向上位机、物联网平台、或者要交一个能演示的毕业设计的工程师新手能照着搭出最小系统熟手能对照检查自己的参数边界。2. 先定架构智能风电场系统为什么很少一上来就上微服务2.1 从 PDF 里的功能条目反推技术栈一份典型的智能风电场系统需求拆开看无非四块数据采集、数据存储、实时监控、统计分析。很多人的第一反应是 Spring Cloud 加 Kafka 加 Flink 加 ClickHouse一套下来光环境就能搭两天。但风电场现场的现实是风机主控 PLC 走 Modbus TCP 或 OPC UA单台风机测点通常在 50 到 200 个之间整场 20 台风机满打满算一万个测点采样周期 1 秒到 10 秒可调。这个量级用单体应用加时序数据库完全扛得住上微服务反而让部署和排错变成玄学。我一般会推荐这样的分层采集层用 Python 或 Go 写一个常驻进程按风机 IP 轮询消息层用 Redis 的 Stream 或者直接写本地磁盘队列做缓冲存储层用 TDengine 或 InfluxDB 存时序数据MySQL 存风机台账和告警记录展示层用 Grafana 或者自己写一个 Vue 页面调 WebSocket。这套组合在一台 8 核 16G 的工控机上就能跑现场断电重启后恢复也快。选型理由要落到参数上TDengine 建库时KEEP设 365 天DAYS设 10CACHEMODEL开both这样最近数据和历史数据查询都不会太慢。InfluxDB 则要注意retention policy别设成 autogen 无限保留风机数据一天一万测点乘 86400 秒不加限制磁盘三个月就满。2.2 最小可运行拓扑与端口规划在动手写代码之前先把网络拓扑在纸上画一遍。风电场通常分管理大区和生产大区中间有隔离装置。如果只是做演示或课程设计可以简化为一个局域网一台采集服务器双网卡一张网卡连风机网段一张网卡连办公网段。端口规划上Modbus TCP 默认 502OPC UA 默认 4840TDengine 默认 6041Grafana 默认 3000。这些端口在现场经常被防火墙拦提前找网络组开白名单比写完代码再排查快得多。下面是一个用 Python 做 Modbus TCP 采集的最小示例假设风机 PLC 的寄存器地址已经拿到风速在 40001有功功率在 40003都是 16 位无符号整数需要除以 10 得到实际值。from pymodbus.client import ModbusTcpClient import time import json # 风机 PLC 的 IP 和端口现场按实际改 PLC_IP 192.168.1.101 PLC_PORT 502 client ModbusTcpClient(PLC_IP, portPLC_PORT) client.connect() def read_wind_turbine(): # 读保持寄存器起始地址 0 对应 40001数量 4 个 rr client.read_holding_registers(address0, count4, slave1) if rr.isError(): print(读取失败检查链路) return None wind_speed rr.registers[0] / 10.0 # 风速单位 m/s active_power rr.registers[2] / 10.0 # 有功功率单位 kW return {wind_speed: wind_speed, active_power: active_power, ts: int(time.time())} while True: data read_wind_turbine() if data: # 这里先打印实际项目写入 Redis Stream 或直接入库 print(json.dumps(data)) time.sleep(1) # 采样周期 1 秒现场可放宽到 5 秒这段代码的逻辑很直白建立 TCP 连接按寄存器地址读四个值取前两个做缩放。参数说明上address0对应 Modbus 协议里的 40001如果 PDF 里给的是 30001 开头的输入寄存器要换成read_input_registers。slave1是风机从站号多台风机串联时这个值必须区分开。time.sleep(1)是采样间隔现场如果测点超过 100 个建议改成 5 秒否则 PLC 的 TCP 连接数会被占满。注意Modbus TCP 没有断线重连机制client.connect()返回 True 不代表后续读取一定成功。生产环境要在循环里加异常捕获失败后client.close()再重新连接否则程序会卡死在读操作上。3. 数据落库与实时告警智能风电场系统的存储表怎么建才不后悔3.1 时序库建表与写入参数数据采上来之后第一件事是决定存哪里。用 MySQL 存时序数据不是不行但一天一千万行之后SELECT最近一小时的数据都要几秒。TDengine 的超级表模型很适合这个场景一张超级表按风机编号建子表每个测点一列。建表语句如下。-- 创建超级表采集周期 1 秒保留 365 天 CREATE STABLE wind_turbine ( ts TIMESTAMP, wind_speed FLOAT, active_power FLOAT, rotor_speed FLOAT, gearbox_temp FLOAT ) TAGS ( turbine_id BINARY(16), farm_id BINARY(16) ); -- 为 1 号风机建子表 CREATE TABLE turbine_001 USING wind_turbine TAGS (WT001, FARM_A);参数上TIMESTAMP默认毫秒精度如果 PDF 要求微秒建库时指定PRECISION us。FLOAT占 4 字节风机测点用FLOAT足够别用DOUBLE浪费空间。TAGS里的turbine_id是标签查询时按标签过滤比按列过滤快一个数量级。写入时用参数绑定不要拼 SQL 字符串否则测点一多解析开销很大。写入的 Python 示例import taosrest conn taosrest.connect(urlhttp://localhost:6041, tokenyour_token) cursor conn.cursor() # 批量写入一次 100 条减少网络往返 sql INSERT INTO turbine_001 VALUES (%s, %s, %s, %s, %s) data [(1690000000000, 5.2, 1200.5, 15.3, 45.2), (1690000001000, 5.3, 1210.0, 15.4, 45.3)] cursor.executemany(sql, data) conn.commit()executemany比单条execute快很多批量大小控制在 100 到 500 之间太大反而容易超时。taosrest走 HTTP 6041 端口如果现场对性能要求高换taos原生连接走 6030 端口。3.2 告警规则与防抖动处理智能风电场系统里告警是甲方最看重的功能也是最容易翻车的地方。齿轮箱温度超过 80 度告警这个规则写起来一行代码但风机在夏天满发时温度本来就在 75 到 85 之间波动如果直接if temp 80: alarm()运维人员的手机一天能收几百条短信最后的结果是把告警关掉。常见的做法是加迟滞和持续时间判断温度超过 80 度且持续 30 秒才触发触发后要等温度降到 75 度以下才恢复。用 Redis 的过期键或者内存状态机都能实现。下面是一个简化的状态机逻辑。import time class AlarmState: def __init__(self, high80.0, low75.0, duration30): self.high high self.low low self.duration duration self.trigger_time None self.active False def update(self, temp): now time.time() if not self.active: if temp self.high: if self.trigger_time is None: self.trigger_time now elif now - self.trigger_time self.duration: self.active True self.trigger_time None return ALARM_ON else: self.trigger_time None else: if temp self.low: self.active False return ALARM_OFF return Nonehigh和low之间的差值叫死区一般取量程的 5% 到 10%。duration根据测点变化速率定温度这种慢变量 30 秒合理振动这种快变量可以缩到 5 秒。这段逻辑要放在采集进程里不要放在数据库的定时任务里否则采样间隔和判断间隔对不上会出现漏报。提示告警记录一定要单独存一张表包含触发时间、恢复时间、测点值、规则编号。事后追查时这张表比时序数据更有用。4. 避坑与排查智能风电场系统上线前必须过的五道坎4.1 风机数据时间戳对不齐现象Grafana 上画出来的风速和功率曲线错位功率变化总是比风速晚几秒。原因采集程序用本地时间打时间戳但不同风机的 PLC 响应延迟不一样有的 50 毫秒有的 500 毫秒批量写入时顺序乱了。解决在采集端统一用time.time()打时间戳不要用 PLC 返回的时间如果 PLC 支持读它的系统时间做校准入库时按时间戳排序TDengine 会自动处理乱序数据但查询时加ORDER BY ts更稳妥。4.2 Modbus 读取返回 Exception Code现象程序日志里频繁出现Exception Response (131, 2)。原因131 是功能码 3 加 1282 表示非法数据地址。PDF 里给的寄存器地址可能是从 1 开始计数的而代码里从 0 开始。解决确认地址偏移40001 对应代码里的 030001 对应输入寄存器且代码里也要从 0 开始。如果还不行用 Modbus Poll 工具先手动读一次确认地址和从站号。4.3 时序数据库磁盘写满现象系统运行两周后写入变慢最后报错。原因TDengine 默认KEEP是 3650 天数据文件一直不删。解决建库时显式指定KEEP 365并设置DAYS 10让数据按天分片。同时加一个定时任务每天检查磁盘使用率超过 80% 就清理临时文件或扩容。4.4 告警风暴导致短信通道被封现象大风天过后运维人员收到上千条告警短信运营商把短信接口限流了。原因没有做告警合并和抑制。解决同一台风机同一类告警在 5 分钟内只发一次如果整场多台风机同时告警合并成一条汇总消息。这个逻辑可以在告警服务里加一个 Redis 的SETNX带过期时间来实现。4.5 前端 WebSocket 断连后数据不更新现象监控大屏开着过一段时间数字不动了刷新页面才恢复。原因WebSocket 没有心跳中间的网络设备把空闲连接断了。解决前端每 30 秒发一个 ping后端回 pong断连后前端自动重连重连时带上最后一条数据的时间戳后端补发断连期间的数据。这个补发逻辑用 TDengine 的INTERVAL查询很容易实现。5. 从能跑到好用智能风电场系统的数据补传与压测技巧5.1 断网续传的本地队列设计风电场现场网络抖动是常态采集程序不能因为写库失败就把数据丢了。我一般会在采集和入库之间加一个本地磁盘队列用 SQLite 或者文件追加的方式。采集线程只管往队列里写入库线程从队列里读读一条删一条。网络恢复后入库线程自动把积压的数据补上。SQLite 的WAL模式在这种场景下很稳写入不会阻塞读取。import sqlite3 # 本地队列WAL 模式提高并发 conn sqlite3.connect(buffer.db) conn.execute(PRAGMA journal_modeWAL) conn.execute(CREATE TABLE IF NOT EXISTS queue (id INTEGER PRIMARY KEY, payload TEXT)) def enqueue(payload): conn.execute(INSERT INTO queue (payload) VALUES (?), (payload,)) conn.commit() def dequeue(): row conn.execute(SELECT id, payload FROM queue ORDER BY id LIMIT 1).fetchone() if row: conn.execute(DELETE FROM queue WHERE id?, (row[0],)) conn.commit() return row[1] return NoneWAL模式让写和读可以同时进行ORDER BY id保证先进先出。队列文件要放在 SSD 上机械硬盘在频繁小写入时延迟很高。队列长度超过 10 万条时报警说明后端入库出了问题。5.2 用模拟数据做一次压力测试系统上线前最好用模拟数据压一遍。写一个脚本模拟 20 台风机、每台 100 个测点、1 秒采集一次连续跑 1 小时看采集进程的内存和 CPU、数据库的写入延迟、前端页面的刷新帧率。压测时把采样周期改成 100 毫秒相当于 10 倍压力如果 10 倍压力下系统不崩现场 1 秒周期就稳了。压测中重点看三个指标采集进程的常驻内存是否持续增长内存泄漏、数据库的INSERT耗时是否稳定在 10 毫秒以内、WebSocket 推送延迟是否小于 2 秒。任何一个不达标先解决再上线。5.3 一个我踩过的坑别在采集进程里做复杂计算早期版本我把功率曲线拟合、振动频谱分析都放在采集进程里结果采样周期一波动计算任务把采集线程堵死了。后来改成采集进程只做读取和入队计算任务单独起一个消费者进程从队列里拿数据算。这个拆分让采集的稳定性提升了一个档次。记住一句话采集进程越薄越稳计算再重也别堵在采集上。希望帮到你。本文还有配套的精品资源点击获取
