如何设计一个具备“平滑指数退避”特征的 Promise 异步任务高可用调度系统-js教程-PHP中文网

平滑指数退避需抖动+响应优先+令牌桶协同：用随机因子避免重试共振，优先采用retry-after头，结合令牌桶限频；调度器须支持cancel/pause，时间计量改用performance.now()并节流localstorage同步。

如何设计一个具备“平滑指数退避”特征的 promise 异步任务高可用调度系统

平滑指数退避不是简单地用 Math.pow(2, n) 硬切时间片，而是要在重试间隔中引入随机扰动、动态响应服务反馈（如 Retry-After）、并和限频机制耦合——否则容易在下游恢复瞬间引发请求洪峰。

纯指数增长的延迟曲线太陡峭且确定，实际场景中会出现两个典型问题：

多个客户端在同一失败点重试时，会在第 3 次重试后几乎同时发起请求，形成“重试共振”，反而压垮刚恢复的服务
当后端返回 503 Service Unavailable 并带 Retry-After: 12 时，若仍坚持按 baseDelay * 2^attempt 算出 8000ms，就浪费了服务端给出的精确调度信号
没有对单位时间总请求数做约束，比如每分钟最多允许 5 次重试，否则即使单次退避拉长，高频触发任务仍可能突破 QPS 阈值

真正的平滑不靠“更精细的 baseDelay”，而靠三个动作的叠加：

ChatLaw

ChatLaw是一款AI法律服务工具，北大开源的法律大模型和助手。

下载

抖动（Jitter）：每次计算延迟后乘以 0.5 ~ 1.0 的随机因子，例如 delay = baseDelay * Math.pow(2, attempt) * Math.random() * 0.5 + 0.5，避免集群重试同步化
响应优先（Response-aware）：在 catch 块中解析 err.response?.headers.get('Retry-After')，若存在则直接用该值（单位秒），并跳过指数计算；对 429 响应也同理处理
令牌桶协同：维护一个 Map<string number></string> 记录每个 url 最近 60 秒内所有重试发起时间戳，每次重试前过滤过期项，若剩余数量 ≥ 阈值（如 5），则强制将本次 delay 设为 60000 - (Date.now() - earliestTimestamp)

高可用 ≠ 无限重试。生产环境里，一个卡住的异步任务如果不能被外部干预，就会拖垮整个调度队列：

requestWithRetry 函数应返回一个带 cancel() 方法的对象，内部用 AbortController 控制 fetch，并在 cancel() 中调用 abort() 清理未决 Promise
调度器实例需支持 pause(urlPattern: RegExp)，匹配到的 URL 后续重试全部进入等待队列，直到 resume() 被调用——这对灰度发布或紧急熔断至关重要
不要把重试逻辑全塞进单个 async 函数里；应拆成 scheduleAttempt()（决定是否重试+算 delay）、executeWithTimeout()（封装 fetch + AbortSignal）、recordOutcome()（更新令牌桶）三个可单独测试的单元

浏览器环境里，用户切换标签页、系统休眠、NTP 校时都可能导致 Date.now() 跳变。如果你用它计算“60 秒窗口”，就可能漏判或误判令牌桶状态。解决方案只有两个：

改用 performance.now() 做相对时间计量，配合启动时记录的 startTime = performance.now()，所有“60 秒”逻辑转为 if (performance.now() - startTime > 60000)
若需跨 Tab 共享令牌桶状态（比如防止用户开 5 个页面同时刷接口），必须用 localStorage + storage 事件同步，但要注意写入频率——每毫秒一次 update 会卡死主线程，应节流到至少 100ms 一次