Job queues 的陷阱：看似简单实则复杂
Job queues are deceptively tricky
作为一名程序员，我最近深入思考了 Job queues 的设计，发现它表面简单，实则暗藏玄机。在 $WORK 处理 reference repos 的 repacking 任务时，我们面临 Wholesale repacking（耗时 7 小时但体积更小）和 Incremental repacking（耗时 2 小时但更新更快）的抉择。直觉上，周末做 Wholesale、工作日做 Incremental 似乎是完美方案，但 Job queues 的调度机制却没那么听话。当调度间隔与任务时长不匹配时，Parallel Spawn、Prefer New、Wait 或 Prefer Old 等不同语义会导致意想不到的行为。这让我意识到，理解队列的底层逻辑和故障模型，比单纯配置参数更重要。
现实往往拥有令人惊讶的细节，这让我们原本以为简单的系统，在深入探索后展现出复杂的内在面。
HN 评论区
48- 排队论的核心反直觉结论是：系统利用率与延迟呈非线性关系，当利用率接近 100% 时，平均等待时间会呈双曲线式急剧增长。
- Google 在某些广告竞价场景下采用 'prefer new' 策略（即栈而非队列），因为对于时效性敏感的任务，丢弃旧请求比延迟处理更有价值。
- 用户感知对尾部延迟（tail latency）极度敏感，偶发的长延迟会破坏整体体验，迫使系统必须预留冗余容量而非单纯依赖队列削峰。
- 队列系统可能将简单的故障转化为级联故障，例如服务重启时积压请求瞬间涌入，导致部分恢复的服务再次过载崩溃。
- 针对 IO 密集型且流量波动大的场景，基于 CPU 指标的传统扩缩容失效，应改为根据队列大小和输入输出速率进行独立于消费者的自动扩缩容。