Serverless GPU 异步调度心跳与熔断器自愈手记

1. 起因：一次由“本地假想敌”引发的线上雪崩

最近在自建的长耗时 GPU 图层分离推理管线中，遭遇了一起让人哭笑不得的“连环踩踏”事故。

有几个大分辨率图片的生成任务线上频频报失败，查看后台发现一个诡异现象：本地调度器判定任务“超时失败”，而远端 Serverless GPU 容器其实还在兢兢业业地排队或跑推理。更糟的是，本地超时判定直接调用了错误上报，累积 3 次失败后把本地熔断器打到了 OPEN 状态；而冷却期过后进入 HALF_OPEN 时，单次试探任务又卡在队列，没有超时释放机制，导致锁死，直接将后续所有正常任务在队列里活活憋了整整 8 个小时。

2. 根因剖析与两次架构反思

我最初的修补方案很想当然：既然是超时，那我就把超时上限从 10 分钟强行提到 25 分钟，甚至去数据库篡改认领时间戳 claimedAt 来让前端进度条不穿帮。

但在深入代码推敲后，才意识到这是一个典型的客户端权责越界与假想敌：

1. 本地超时根本杀不掉远程 GPU： 本地调度器只是一个轻量的轮询客户端（通过 HTTP GET 查状态）。本地单方面判定 25 分钟把数据库改成 failed，并不会向远程 Serverless 集群发送任何中断信号。该跑的计算仍在跑，该烧的显卡费一分没省。
2. GPU 超时的真身在运行时本身： 远程 Serverless GPU 入口早就配置了 @app.cls(timeout=600)。只要单次容器执行真死锁或死循环，底层的沙箱在满 10 分钟时自然会将其物理掐断并返回明确的 status: "error"。
3. 本地 Timeout 真正防的只有一件事情：失联。 只有在网络分区、API 网关 502/504、DNS 故障、持续拿不到远端心跳响应时，本地计时器才应该扮演“兜底超时”的裁决者。

3. 重构实践：基于健康心跳与试探锁自愈

理顺权责边界后，代码重构变得极度克制而干净：

A. 调度器：只要有心跳（running/pending），就恒定保活

放弃所有篡改时间戳的黑魔法，将轮询状态判定收敛为四种标准语义：

• 成功：status === "success"，落盘持久化。
• 明确报错：status === "error"（含远程运行时 600s 强杀），立刻接管失败逻辑并释放用户并发锁。
• 健康心跳：status === "running" | "queued"，只要远端还在应答，本地绝对信任并维持心跳，进度条平滑封顶在 98% 等待交卷。
• 失联超时：仅在 result === null（网络彻底断连）连续持续超过 10 分钟时，才触发本地超时。

// 纯粹的心跳保活策略
const isHeartbeatAlive =
  !!result &&
  (result.status === "running" ||
    result.status === "queued" ||
    result.status === "pending" ||
    result.status === "starting");

const now = Date.now();
const timeSinceLastHeartbeat = now - (job.updatedAt || job.claimedAt);

// 只要心跳活着，绝不误杀；仅在失联持续超 10 分钟时判定超时
const isWithinTimeout = isHeartbeatAlive || timeSinceLastHeartbeat <= 10 * 60 * 1000;

B. 熔断器：半开试探锁增加 10 分钟自愈

在 HALF_OPEN 状态下增加时间戳监测，若试探任务超过 10 分钟未给出裁决，自动解开试探互斥锁，允许后续请求继续试探，杜绝单次抖动造成全站永久封死：

if (store.state === "HALF_OPEN") {
  if (
    store.halfOpenTrialInFlight &&
    store.halfOpenTrialStartTime &&
    now - store.halfOpenTrialStartTime > 10 * 60 * 1000
  ) {
    store.halfOpenTrialInFlight = false;
  }
}

4. 结语

在分布式与 Serverless 系统的边界上，客户端最容易犯的错误就是“自以为是地替服务端做主”。弄清楚谁拥有容器的控制权，谁负责发出生命体征（Heartbeat），谁负责在失去信号时拉响警报，比在本地写一堆复杂的延时和重试胶水代码管用得多。