一、场景与量级
区域级资产包里往往同时存在多品牌逆变器、储能设备与多批次固件。写入量按「站点数 × 单站测点数 ÷ 上报周期」估算，再按告警峰值留余量。上报周期缩短一半，写入压力大致翻倍，手机端的处理能力并没有跟着变。
这决定了光伏电站APP监控平台的四层不能同步耦合：接入侧要有缓冲，时序侧要能批量落库，事件侧要收敛，投递侧要处理弱网与重试。任何一层直接同步调用下一层，都会把设备侧的抖动放大成终端的消息风暴。
二、三个工程约束
上报节奏与消费节奏不对称，是第一个约束。设备按固定周期上报，告警判定与手机推送却集中在异常发生的短窗口里，瞬时压力远高于平均值。
重复上报与收敛窗口，是第二个约束。通信抖动会让同一故障在几秒内重复上报多次，若每次都生成事件，值班组会被同一条故障反复提醒。
终端离线与状态倒退，是第三个约束。现场信号不稳时，回执可能延迟或重复到达；若状态按最后一条回执覆盖，复核完成的状态可能被一条迟到的「已派单」拉回去。
三、数据模型
三张表撑起主链路，event_id 贯穿始终：
CREATE TABLE device_point (
station_id VARCHAR(32),
device_id VARCHAR(64),
point_code VARCHAR(64),
pt_version VARCHAR(32),
ts TIMESTAMP,
raw_value DECIMAL(14, 4),
fixed_value DECIMAL(14, 4),
PRIMARY KEY (device_id, point_code, ts)
);
CREATE TABLE alarm_event (
event_id VARCHAR(64) PRIMARY KEY,
device_id VARCHAR(64),
alarm_code VARCHAR(32),
priority SMALLINT,
first_seen_at TIMESTAMP,
last_seen_at TIMESTAMP,
repeat_count INT,
window_tag VARCHAR(32)
);
CREATE TABLE dispatch_log (
event_id VARCHAR(64),
receiver_group VARCHAR(32),
target_status VARCHAR(16),
idempotency_key VARCHAR(128) UNIQUE,
written_at TIMESTAMP
);
device_point.pt_version 不能省。它把数值和当时的点表快照绑在一起，固件升级后历史值仍按原版本解析，不回刷、不覆盖。alarm_event.window_tag 用来标记收敛窗口，复盘时能说明一次合并发生在哪个时间片。
四、关键设计
4.1 接入缓冲与批量落库
接入层先把上报写进缓冲区，再按批次落时序库，避免设备抖动直接穿透到判定层。配置可以按站点分级：
ingest:
buffer_window_ms: 2000
batch_size: 500
retry:
max_attempts: 3
backoff_ms: 500
overflow: drop_oldest_and_alert
缓冲区溢出时丢弃最旧批次并单独告警，不静默丢数据。这一条要写进运维手册，否则排查时容易误判成设备离线。
4.2 去重窗口与优先级旁路
去重键取「设备 ID + 告警码 + 未闭环状态」，窗口内只更新次数与最近发生时间。并网类、安全类告警按优先级直达，不进合并：
IF priority IN ('grid', 'safety') THEN bypass_dedup
ELSE IF same(device_id, alarm_code) AND status != 'archived'
WITHIN window_tag THEN merge ELSE create
忽略旁路规则，收敛会从减负变成漏报。站级汇总另走一层，避免与设备级告警同时推给同一个人。
4.3 状态机与幂等回写
状态固定为：待确认 → 已派单 → 处理中 → 已复核 → 归档，只允许正向流转。复核不通过时追加一条新记录并标明原因，不覆盖旧值；迟到回执按 idempotency_key 直接丢弃，不把状态拉回去。
幂等键取「事件 ID + 值班组 + 目标状态」，写进 dispatch_log 的 UNIQUE 约束。手机端只保留签收、到场、提交结果三个动作，处理结论写回原事件。
4.4 冷热分层与回溯
近期窗口保留明细时序，历史窗口按站点与天做聚合归档；回溯时先查聚合，再按 pt_version 下钻到明细。光伏电站APP监控平台的容量规划要把「在线查询」与「历史回溯」分开评估，否则加站点时容易被回溯查询拖垮在线写入。
五、实施边界
- 写入量按公式估算后按峰值留余量；不做未经实测的性能承诺。
- 存量网关拿不到稳定点表时保留原采集通道旁路接入，不为了一张统一视图替换现场设备。
- 复杂计算留在服务端：功率预测、离散率分析、对标分析只把结论与依据送到终端。
- 外部系统只做接口对齐，保留原有账套；事件 ID 与点表版本作为两侧对齐键。
六、小结
光伏电站APP监控平台的差别，多数不在界面上。点表有没有版本、重复上报有没有收敛窗口、回执能不能幂等回到原事件，决定的是值班人员愿不愿意真的用它。把这三件事做实，移动端才不会变成第二块大屏。
常见问题
问：光伏电站APP监控平台的时序数据要不要做冷热分层？
答：要。近期窗口留明细，历史窗口按站点与天聚合归档；回溯先查聚合再下钻，避免加站点后被历史查询拖垮在线写入。
问：去重窗口设多长合适？
答：按同类故障的自然恢复时间定，并允许按站调整。窗口太短会重复提醒，太长会把不同时段的故障并成一条，历史次数失真。
问：接入层抖动会不会重复生成告警？
答：不会。规则层消费的是已批量落库的时序快照，重复上报在事件归一层按去重键合并，不直接穿透到告警判定。
问：离线回执重复到达会不会生成两张工单？
答：不会。回执按「事件 ID + 值班组 + 目标状态」作幂等键，重复或迟到到达直接丢弃，状态也不会被拉回。
