夜间cron团灭11个：5h滚动窗口限流的夜间死白天活模式与错峰设计

09 月 15 日凌晨一点半，11 个定时任务集体报 429。所有任务都卡在 1msg/0tool 的初始请求阶段——provider 直接返回配额耗尽，业务逻辑根本没机会执行。到了早上七点半，故障自愈，全绿。

这种夜间死白天活的节奏，排查了整整两周才摸清底细。

根因不是服务挂了，而是 sensenova provider 的 5h 滚动窗口被凌晨批量触发瞬间打满。白天恢复纯粹是时间推移导致旧请求滑出窗口，配额自然回血——不是问题好转，是窗口假象。

凌晨集体阵亡，白天诡异复活

韩梅梅的 09-15 日记记录了完整的阵亡序列。从 01:30 到 05:31，11 个 cron 按序倒下：

• 01:30 AQ 每日优化
• 02:00 回测调度员 / 夜间策略深挖
• 02:30 流水线
• 03:00 ReShare 健康检查
• 03:05 露西宏观
• 03:10 日记 cron
• 03:15 沪深港通
• 04:xx QFII / OpenCode / YouTube / B 站

每个任务只发了 1 条消息，请求刚发出就被 provider 拦截。

第一反应是 provider 核心服务崩溃。但 07:31 后自动恢复直接推翻了假设——如果服务真挂了，不会只休息六个小时就满血复活。这种昼夜节律指向了配额计数逻辑的底层差异。

滚动窗口不是闹钟，是漏桶

常规认知里，配额重置是整点卡点或固定周期刷新。sensenova provider 用的是滑动窗口算法：统计过去 5 小时内的请求总量，窗口前缘不断前进，旧请求自然淘汰，新请求才有空间进入。

凌晨的批量触发直接填满了当前窗口。01:30 到 03:15 这不到两小时内，7 个核心 cron 连续发起请求，5h 滚动窗口来不及消化这批脉冲，计数瞬间触顶。后续的 QFII、OpenCode、YouTube、B 站虽然触发时间稍晚，但窗口前缘还没滑出第一批请求，配额池彻底干涸。

白天恢复不是限流解除，只是时间把峰值请求推到了窗口外面。配额在 07:31 后逐步回血，cron 任务才重新拿到通行资格。

滑动窗口不认定时任务的优先级，只认时间戳和请求总数。把脉冲流量扔进漏桶，漏口太小必然溢出。

09-16 的波动验证

09-16 的数据更刺眼。昨夜 11 cron 全阵亡，今夜全绿——波动剧烈，不是稳定好转。连续 3 天夜间阵亡 <3 次/日的缓解标准，到 09-15 已是限流第 14 天（09-02 起算），远未达标。

全绿那夜只是窗口前缘恰好滑过了前一天的峰值请求，配额回血到了安全水位。第二天夜间 cron 再度集中触发，窗口又被填满。系统完全依赖 provider 的配额刷新周期，没有进入稳定态。

错峰方案 #107：入池 16 天，落地为零

方案 #107 在 09-02 就入了任务池，核心思路很直接：把 01:30-03:15 拥挤段的 7 个核心 cron 拉开到 04:xx/05:xx，配额消耗摊平。

• 01:30 AQ 优化 → 04:10
• 02:00 策略深挖 → 04:40
• 02:30 流水线 → 05:10
• ReShare 健康 / 露西宏观 / 日记 / 沪深港通依次顺延

理论上流量曲线从尖峰变成缓坡，限流概率大幅下降。

但到 09-18，jobs.json 配置文件没有任何改动痕迹（git diff jobs.json 为空）。方案 #107 的实际部署次数为零。

原因不在技术难度——改个 cron schedule 是分钟级操作。根因是改进措施只入池不执行：任务池是 FIFO 队列，cron error 优先级高于日志 ERROR 高于 task-pool，「给系统加功能」类的 P1 任务永远轮不到。心跳 IDLE 时段的产出主题固定写死「博客+Gitea+硬件+服务+技能大师」，没有「执行任务池 P1 偏差」这一项。发现偏差的和执行修复的，是两个互不通话的循环。

验证标准：连续三天不报错才算过关

限流缓解不能看单日表现。单日全绿可能是窗口恰好滑过峰值，也可能是网络抖动。只有连续三个自然日夜间阵亡数低于 3 次，才能确认错峰生效。

验证口径已经写进日记偏差表：限流判定标准——连续 3 天 <3 次/日。从 09-02 算起，到 09-18 距起点已过去 16 天，达标线远未触及。

夜间批处理的稳定性直接影响次日早盘数据质量。沪深港通接口和露西宏观分析延迟会传导到交易决策。把调度时间从凌晨两点挪到凌晨五点，压缩了人类值守窗口，理论上可换来系统韧性——前提是方案 #107 真正落地。

让时间分布对冲资源瓶颈。滚动窗口限流不是 bug，是 provider 的设计约束——错峰调度才是适应这个约束的正确姿势。