Hogyan terveznél ütemezőt 10M időzített feladathoz?

Question

IT Interview Practice · Accepted Answer

Tárold a feladatokat egy **idő-vödrös / prioritási queue-ban** esedékességi idő szerint kulcsolva, csak a *most* esedékes feladatokat pollozd, és add át őket idempotens workereknek **at-least-once** kézbesítéssel. Soha ne szkennelj 10M sort minden tickben — indexelj indítási idő szerint, hogy minden poll csak azt érintse, ami esedékes.

## Architektúra

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

## Komponensek és folyamat

- **Indítási idő szerint indexelt task store**: egy Redis sorted set (`ZADD tasks score=due_ts`) vagy egy `(run_at)`-en indexelt DB tábla. A `ZPOPMIN`/`ZRANGEBYSCORE now` csak az ebben a másodpercben esedékes feladatokat húzza ki — O(log n), nem táblaszken. A task-id szerinti **shardelés/partícionálás** 10M feladatot terít szét node-okon, így egyetlen store sem forró.
- **Poller leader electionnel**: minden partíciónak egy aktív pollere van, etcd/ZooKeeper-en keresztül választva; a standbyok átveszik hiba esetén. Egy leader partíciónként megakadályozza, hogy két poller ugyanazt a feladatot dispatchelje, míg a partícionálás magasan tartja a throughputot.
- **Ready queue (Kafka)**: az esedékes feladatok sorba kerülnek, szétcsatolva az *ütemezést* a *végrehajtástól*. A workerek a pollertől függetlenül skálázódnak.
- **Idempotens workerek** végrehajtanak és **ackelnek**. Mivel a kézbesítés at-least-once, egy feladat kétszer futhat (a poller összeomlott dispatch után, kész-jelölés előtt) — így magának a munkának idempotensnek kell lennie, `task_id`-re kulcsolva, különben duplán terheled meg a vevőt. A hibák backoffal újrapróbálódnak, majd egy DLQ-ba kerülnek.

## Interjú szemszög

Az interjúztató két dolgot vizsgál: a **hatékony idő-keresést** és az **exactly-once vs at-least-once**-t. A "jó" egy cron ciklus egy táblán; a "kiváló" a sorted-set index plusz az őszinte beismerés, hogy az elosztott exactly-once kivitelezhetetlen, ezért **at-least-once + idempotens workert** választasz. Klasszikus csapda: egyetlen ütemező node-ra támaszkodni — az SPOF és throughput-plafon. Egy másik: túl durván pollozni (percenként), amikor a feladatoknak másodperces pontosság kell, vagy túl finoman és bombázni a store-t.

## Kompromisszumok és hibák

- **Pontosság vs terhelés**: az 1 mp-es tick másodperc-szintű pontosságot ad de több pollt; vödrözd a feladatokat percenkénti majd másodpercenkénti al-queue-kba, hogy csökkentsd a szken költséget (a Kafka és Quartz által használt "timing wheel" / hashed-wheel megközelítés).
- **At-least-once vs exactly-once**: nem érhetsz el valódi exactly-once-t egy crash határon át; az idempotencia kulcsok ártalmatlanná teszik a dupla végrehajtást — ez a helyes kompromisszum.
- **Hiba**: ha egy poller dispatch közben elszáll, a leader election előléptet egy standbyt és a nem ackelt feladatok újraküldődnek — semmi nem vész el, néhány ismétlődhet. Figyeld az **óra-eltérést (clock skew)** a node-ok között (NTP), különben a feladatok korán/későn indulnak; és korlátozd a retryket, hogy egy tartósan hibázó feladat ne cikluzzon örökké — küldd a DLQ-ba vizsgálatra.

Architektúra

Komponensek és folyamat

Interjú szemszög

Kompromisszumok és hibák

Kapcsolódó kérdések