Как бы вы спроектировали планировщик на 10 млн отложенных задач?

Question

IT Interview Practice · Accepted Answer

Храните задачи в **очереди с временными бакетами / приоритетной очереди** по времени срабатывания, опрашивайте только задачи, срок которых наступил *сейчас*, и передавайте их идемпотентным воркерам с доставкой **at-least-once**. Никогда не сканируйте 10 млн строк на каждый тик — индексируйте по времени срабатывания, чтобы каждый опрос касался только того, что подошло по сроку.

## Архитектура

```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
```

## Компоненты и поток

- **Хранилище задач, индексированное по времени срабатывания**: sorted set в Redis (`ZADD tasks score=due_ts`) или таблица в БД с индексом на `(run_at)`. `ZPOPMIN`/`ZRANGEBYSCORE now` достаёт только задачи, срок которых наступил в эту секунду — O(log n), а не скан таблицы. **Шардирование/партиционирование** по task-id распределяет 10 млн задач по узлам, так что ни одно хранилище не горячее.
- **Poller с выбором лидера (leader election)**: у каждой партиции один активный poller, выбранный через etcd/ZooKeeper; резервные подхватывают при сбое. Один лидер на партицию не даёт двум poller-ам диспетчеризовать одну задачу, а партиционирование держит throughput высоким.
- **Очередь готовых (Kafka)**: подошедшие задачи ставятся в очередь, отделяя *планирование* от *выполнения*. Воркеры масштабируются независимо от poller-а.
- **Идемпотентные воркеры** выполняют и делают **ack**. Поскольку доставка at-least-once, задача может выполниться дважды (poller упал после диспетчеризации, до отметки о завершении) — поэтому сама работа должна быть идемпотентной, по ключу `task_id`, иначе вы дважды спишете деньги с клиента. Сбои повторяются с backoff, затем попадают в DLQ.

## Взгляд с точки зрения интервью

Интервьюер прощупывает две вещи: **эффективный поиск по времени** и **exactly-once против at-least-once**. «Хорошо» — cron-цикл по таблице; «отлично» — индекс на sorted set плюс честное признание, что распределённый exactly-once непрактичен, поэтому вы выбираете **at-least-once + идемпотентные воркеры**. Классическая ловушка: опираться на единственный узел планировщика — это SPOF и потолок throughput. Ещё одна: опрашивать слишком грубо (раз в минуту), когда задачам нужна секундная точность, или слишком часто и долбить хранилище.

## Компромиссы и отказы

- **Точность против нагрузки**: тик в 1 с даёт секундную точность, но больше опросов; раскладывайте задачи в поминутные, затем посекундные под-очереди, чтобы срезать стоимость скана (подход «timing wheel» / hashed-wheel, применяемый в Kafka и Quartz).
- **At-least-once против exactly-once**: истинный exactly-once через границу сбоя недостижим; ключи идемпотентности делают двойное выполнение безвредным — правильный компромисс.
- **Отказ**: если poller умирает посреди диспетчеризации, leader election повышает резервный узел, а неподтверждённые задачи переотправляются — ничего не теряется, кое-что может повториться. Следите за **clock skew** между узлами (NTP), иначе задачи сработают раньше/позже; ограничивайте число повторов, чтобы вечно падающая задача не крутилась бесконечно — отправляйте её в DLQ для разбора.

Архитектура

Компоненты и поток

Взгляд с точки зрения интервью

Компромиссы и отказы

Похожие вопросы