题目重点：系统设计题目强调任务时长未知、长短混合、所有任务最终完成且规模较小；用持久队列与 lease 落地。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版任务有 jobId、tenant、提交时间和可重试执行函数；实际吞吐、deadline、可否抢占与 job 副作用需面试现场确认。
- fairness 训练版定义为各 tenant 按权重长期获得近似执行份额，同时单租户内部 FIFO；不承诺每个任务等待时间完全相同。
解题路线
- 先澄清完成语义：成功终态、失败重试上限、死信/人工处理；未知时长使单队列 FIFO 易被长任务堵塞。
- 小规模首版用持久 DB jobs 表、按 tenant 队列/索引、worker 原子 claim 与 leaseUntil，避免引入不必要的流平台；dispatcher 用轮询/加权公平分配可运行任务。
- worker 定期 heartbeat 续 lease，完成时按 jobId+attempt/version 条件更新；worker 崩溃后 lease 过期再投递，副作用必须幂等或有补偿。
- 长任务若可 checkpoint，可分片/时间片；若不可抢占，至少设不同 worker 池、并发上限与 aging，防短任务/低权重队列饥饿。
- 监控各 tenant 排队等待分位数、执行时长、lease 过期、重试率和完成率；公平性用实际服务份额/等待时间验证。
手动走一遍
训练例：A 队列有一个 2 小时任务与多个秒级任务，B 队列有多个秒级任务。单 worker 严格 FIFO 会让 B 无响应；两 worker 加租户轮询可让 B 至少持续取得执行机会，但 A 的长任务仍需 heartbeat 与幂等续跑。
规模与取舍
J 个待运行任务用 DB 索引选下一个通常随索引查找成本 O(log J) 量级；每 job 的持久状态 O(J)，worker 数 W 决定并行度。题目说规模较小，没有数字，不给固定分片数量。
易错点与追问
容易失分的边界
- 把公平性口号化而不定义指标。
- 未知执行时长仍只用单 FIFO/单 worker。
- lease 到期重试却没处理重复副作用。
- 小规模一上来画大规模 Kafka/Flink 集群。
继续深挖
- 长任务不可抢占怎么办？
- worker 完成后写结果前崩溃会怎样？
- 租户权重和紧急任务如何共存？
- 怎样证明所有任务最终完成？
