Bagaimana anda mereka bentuk scheduler untuk 10J tugasan bermasa?

Question

IT Interview Practice · Accepted Answer

Simpan tugasan dalam **time-bucketed / priority queue** berkunci mengikut masa jatuh tempo, poll hanya tugasan yang jatuh tempo *sekarang*, dan serahkannya kepada worker idempotent dengan penghantaran **at-least-once**. Jangan sekali-kali imbas 10J baris setiap tik — index mengikut masa cetusan supaya setiap poll hanya menyentuh apa yang jatuh tempo.

## Seni bina

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

## Komponen dan aliran

- **Task store terindeks mengikut masa cetusan**: sebuah Redis sorted set (`ZADD tasks score=due_ts`) atau jadual DB terindeks pada `(run_at)`. `ZPOPMIN`/`ZRANGEBYSCORE now` menarik hanya tugasan yang jatuh tempo saat ini — O(log n), bukan imbasan jadual. **Sharding/partitioning** mengikut task-id menyebarkan 10J tugasan merentas node supaya tiada satu store menjadi panas.
- **Poller dengan leader election**: setiap partition mempunyai satu poller aktif yang dipilih melalui etcd/ZooKeeper; standby mengambil alih apabila gagal. Satu leader bagi setiap partition mengelakkan dua poller menghantar tugasan yang sama, sementara partitioning mengekalkan throughput tinggi.
- **Ready queue (Kafka)**: tugasan yang jatuh tempo di-enqueue, men-decouple *penjadualan* daripada *pelaksanaan*. Worker menskala secara bebas daripada poller.
- **Worker idempotent** melaksana dan **ack**. Kerana penghantaran adalah at-least-once, sesuatu tugasan mungkin berjalan dua kali (poller crash selepas dispatch, sebelum menanda selesai) — jadi kerja itu sendiri mesti idempotent, berkunci pada `task_id`, atau anda mengecaj pelanggan dua kali. Kegagalan di-retry dengan backoff, kemudian mendarat di DLQ.

## Perspektif temu duga

Penemu duga menyiasat dua perkara: **carian masa yang cekap** dan **exactly-once vs at-least-once**. "Baik" ialah gelung cron ke atas jadual; "hebat" ialah index sorted-set ditambah pengakuan jujur bahawa exactly-once teragih adalah tidak praktikal, jadi anda memilih **at-least-once + worker idempotent**. Perangkap klasik: bergantung pada satu node scheduler tunggal — ia SPOF dan siling throughput. Satu lagi: poll terlalu kasar (setiap minit) apabila tugasan memerlukan ketepatan saat, atau terlalu halus dan menghentam store.

## Pertukaran dan kegagalan

- **Ketepatan vs beban**: tik 1s memberi ketepatan peringkat saat tetapi lebih banyak poll; bucket tugasan ke dalam sub-queue per-minit kemudian per-saat untuk mengurangkan kos imbasan (pendekatan "timing wheel" / hashed-wheel yang digunakan oleh Kafka dan Quartz).
- **At-least-once vs exactly-once**: anda tidak boleh mendapat exactly-once sebenar merentas sempadan crash; idempotency keys menjadikan pelaksanaan dua kali tidak berbahaya — pertukaran yang betul.
- **Kegagalan**: jika poller mati di tengah-tengah dispatch, leader election menaikkan standby dan tugasan yang belum di-ack dihantar semula — tiada yang hilang, ada yang mungkin berulang. Perhatikan **clock skew** merentas node (NTP) atau tugasan cetus awal/lewat; dan hadkan retry supaya tugasan yang gagal secara kekal tidak bergelung selamanya — hantar ia ke DLQ untuk pemeriksaan.

Seni bina

Komponen dan aliran

Perspektif temu duga

Pertukaran dan kegagalan

Soalan berkaitan