Jak zaprojektowałbyś scheduler dla 10 mln zaplanowanych zadań?

Question

IT Interview Practice · Accepted Answer

Przechowuj zadania w **kolejce z bucketami czasowymi / kolejce priorytetowej** kluczowanej po czasie wykonania, odpytuj tylko zadania należne *teraz* i przekazuj je idempotentnym workerom z dostarczaniem **at-least-once**. Nigdy nie skanuj 10 mln wierszy co tick — indeksuj po czasie odpalenia, aby każde odpytanie dotykało tylko tego, co należne.

## Architektura

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

## Komponenty i przepływ

- **Task store indeksowany po czasie odpalenia**: posortowany zbiór Redis (`ZADD tasks score=due_ts`) lub tabela DB indeksowana po `(run_at)`. `ZPOPMIN`/`ZRANGEBYSCORE now` pobiera tylko zadania należne w tej sekundzie — O(log n), a nie skan tabeli. **Sharding/partycjonowanie** po id zadania rozkłada 10 mln zadań na węzły, więc żaden pojedynczy store nie jest gorący.
- **Poller z elekcją lidera**: każda partycja ma jeden aktywny poller wybrany przez etcd/ZooKeeper; węzły standby przejmują przy awarii. Jeden lider na partycję zapobiega dwóm pollerom dyspozycjonującym to samo zadanie, a partycjonowanie utrzymuje wysoki throughput.
- **Kolejka gotowych (Kafka)**: należne zadania są kolejkowane, co odseparowuje *planowanie* od *wykonania*. Workery skalują się niezależnie od pollera.
- **Idempotentne workery** wykonują i **potwierdzają (ack)**. Ponieważ dostarczanie jest at-least-once, zadanie może wykonać się dwa razy (poller padł po dyspozycji, przed oznaczeniem jako gotowe) — więc sama praca musi być idempotentna, kluczowana po `task_id`, albo obciążysz klienta podwójnie. Awarie są ponawiane z backoffem, potem lądują w DLQ.

## Perspektywa rozmowy kwalifikacyjnej

Rozmówca sonduje dwie rzeczy: **efektywne wyszukiwanie po czasie** oraz **exactly-once vs at-least-once**. „Dobrze" to pętla cron po tabeli; „świetnie" to indeks na posortowanym zbiorze plus szczere przyznanie, że rozproszone exactly-once jest niepraktyczne, więc wybierasz **at-least-once + idempotentne workery**. Klasyczna pułapka: poleganie na pojedynczym węźle schedulera — to SPOF i sufit throughputu. Inna: odpytywanie zbyt zgrubnie (co minutę), gdy zadania wymagają precyzji sekundowej, albo zbyt drobno i katowanie store'a.

## Kompromisy i awarie

- **Precyzja vs obciążenie**: tick 1 s daje dokładność sekundową, ale więcej odpytań; grupuj zadania w podkolejki per-minuta, potem per-sekunda, aby obniżyć koszt skanowania (podejście „timing wheel" / hashed-wheel używane przez Kafkę i Quartza).
- **At-least-once vs exactly-once**: nie osiągniesz prawdziwego exactly-once ponad granicą awarii; klucze idempotentności czynią podwójne wykonanie nieszkodliwym — właściwy kompromis.
- **Awaria**: jeśli poller padnie w trakcie dyspozycji, elekcja lidera promuje standby, a niepotwierdzone zadania są dostarczane ponownie — nic nie ginie, część może się powtórzyć. Uważaj na **clock skew** między węzłami (NTP), bo zadania odpalą się za wcześnie/za późno; i ograniczaj ponowienia, aby trwale wadliwe zadanie nie zapętliło się na zawsze — wyślij je do DLQ do inspekcji.

Architektura

Komponenty i przepływ

Perspektywa rozmowy kwalifikacyjnej

Kompromisy i awarie

Powiązane pytania