MyBatis批量插入：foreach、BATCH、原生JDBC性能实测
2026/10/7 17:00:13
聚合引擎：从单资源到可调容量池
文章目录
- 聚合引擎：从单资源到可调容量池
- 引言：聚合不是加法
- 先对坐标：聚合引擎站在"数据融合三级跳"的中间
- 一、输入单元：档案与评估的合成快照
- 二、分组器：同节点是铁律
- 三、容量池计算器：两层折扣的承诺口径
- 四、反弹效应：200 栋楼不能同时恢复
- 五、快慢接力：储能先上，空调跟上，储能退出
- 六、资源评级与滚动修正
- 七、架构总视角：三层漏斗与信息对等
- 八、指令分解器：先可行性校验，再按有效能力等比分配
- 真实缺陷复盘：负分配是怎么发生的
- 修复后的分解主流程
- 容量预占：同一资源不能在重叠窗口里卖两次
- 九、实测：九个场景全过
- 十、生产扩展条件：教学实现与生产的差距
- 十一、现实对照：接入容量、调节能力与响应实绩
- 十二、学术视角：资源耦合性与多目标聚合
- 十三、现实对照：湖北的"分钟级池 + 秒级池"双池实践
- 结语：容量池建好了，指令该上路了
引言：聚合不是加法
前 13 篇攒齐了零件：档案（第 11 篇）、四类资源的可调容量评估（第 12/13 篇）。本篇把它们组装成引擎——把一万台设备的零散能力，聚合成一个能对电网说"我能调 10MW"的可信容量池。
先破除最大的误区：聚合承诺容量 ≠ 各资源铭牌加总。行业经验里已经给过教训——100 栋楼基准功率加总 120MW，聚类+可靠性+回弹+通信折扣后，能对外承诺的只有约 37-70MW。聚合引擎的核心工作不是加，是打折：每一层折扣都有物理或行为依据，少打一个就是一次响应不合格。
openvpp-aggregator模块交付五个组件：分组器（UnitGrouper）、容量池计算器（CapacityPoolCalculator）、指令分解器（InstructionDecomposer）、任务时间窗（TaskWindow）、容量预占台账（CapacityReservationLedger），10 个单测守住口径（含预占台账的并发回归：登记/查询/释放全方法互斥，并发下不丢更新、不抛并发修改异常）。
先对坐标：聚合引擎站在"数据融合三级跳"的中间
平台里从设备原始数据到市场报价，中间隔着三跳，每一跳的输入输出与负责模块完全不同。先把这张图立起来，避免边界混淆——聚合引擎既不负责清洗原始数据，也不负责决定市场策略：