你会如何为 1000 万个定时任务设计一个调度器？

Question

IT Interview Practice · Accepted Answer

把任务存储在按到期时间为键的**时间分桶 / 优先队列**中，只轮询*当前*到期的任务，并以 **at-least-once** 投递交给幂等的 worker。绝不要每个 tick 都扫描 1000 万行——按触发时间建立 index，使每次轮询只触及到期的任务。

## 架构

```text
API ─▶ Task store (DB/Redis ZSET, score = due_ts)  ── 10M tasks, sharded
             │
     Poller (leader per partition) ── ZPOPMIN due<=now ──▶ Ready queue (Kafka)
             │ leader election (etcd/ZK)                       │
             ▼                                                 ▼
     other pollers idle/standby                       Worker pool (idempotent)
                                                        └─ ack ✔ / retry ✖ ─▶ DLQ
```

## 组件与流程

- **按触发时间建立 index 的任务存储**：一个 Redis sorted set（`ZADD tasks score=due_ts`）或一个在 `(run_at)` 上建 index 的 DB 表。`ZPOPMIN`/`ZRANGEBYSCORE now` 只拉取本秒到期的任务——O(log n)，而非全表扫描。按 task-id 进行 **sharding/partitioning**，把 1000 万任务分散到各节点，使没有单个存储成为热点。
- **带 leader 选举的轮询器（Poller）**：每个 partition 有一个通过 etcd/ZooKeeper 选出的活跃轮询器；备用节点在故障时接管。每个 partition 一个 leader，避免两个轮询器派发同一个任务，而 partition 化保持高 throughput。
- **就绪队列（Kafka）**：到期任务被入队，把*调度*与*执行*解耦。Worker 独立于轮询器进行扩缩容。
- **幂等的 worker** 执行并 **ack**。由于投递是 at-least-once，一个任务可能运行两次（轮询器在派发后、标记完成前崩溃）——因此工作本身必须幂等，以 `task_id` 为键，否则你会对一个客户重复扣费。失败会带退避重试，然后进入 DLQ。

## 面试视角

面试官考察两点：**高效的时间查找**与 **exactly-once 对 at-least-once**。"好"是对一张表做 cron 循环；"出色"是 sorted-set index，加上坦诚承认分布式 exactly-once 不切实际，因此你选择 **at-least-once + 幂等 worker**。一个经典陷阱：依赖单个调度器节点——它既是 SPOF（单点故障）又是 throughput 上限。另一个：在任务需要秒级精度时轮询太粗（每分钟），或太细而猛烈冲击存储。

## 权衡与故障

- **精度与负载**：1 秒 tick 提供秒级精度但轮询更多；把任务分桶到按分钟再按秒的子队列以削减扫描成本（Kafka 和 Quartz 采用的"时间轮（timing wheel）" / 哈希轮方法）。
- **At-least-once 与 exactly-once**：跨越崩溃边界你无法获得真正的 exactly-once；幂等键让重复执行无害——这是正确的取舍。
- **故障**：如果轮询器在派发中途死亡，leader 选举会提升一个备用节点，未 ack 的任务会重投——不会丢失，有些可能重复。留意各节点间的**时钟偏移（clock skew）**（NTP），否则任务会提前/延后触发；并给重试设上限，使一个永久失败的任务不会无限循环——把它送入 DLQ 以供检查。

架构

组件与流程

面试视角

权衡与故障

相关问题