10 milyon zamanlanmış görev için bir scheduler'ı nasıl tasarlarsınız?

Question

IT Interview Practice · Accepted Answer

Görevleri, due time'a göre anahtarlanmış bir **zamana göre bucket'lanmış / priority queue**'da saklayın, yalnızca *şu anda* due olan görevleri poll edin ve onları **at-least-once** teslimat ile idempotent worker'lara verin. Her tick'te asla 10 milyon satır taramayın — fire time'a göre index'leyin, böylece her poll yalnızca due olana dokunur.

## Mimari

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

## Bileşenler ve akış

- **Fire time'a göre index'lenmiş task store**: bir Redis sorted set (`ZADD tasks score=due_ts`) veya `(run_at)` üzerinde index'lenmiş bir DB tablosu. `ZPOPMIN`/`ZRANGEBYSCORE now`, yalnızca bu saniye due olan görevleri çeker — O(log n), bir tablo taraması değil. Task-id'ye göre **sharding/partitioning**, 10 milyon görevi node'lara yayar, böylece hiçbir tek store hot olmaz.
- **Leader election'lı poller**: her partition'ın etcd/ZooKeeper aracılığıyla seçilmiş bir aktif poller'ı vardır; standby'lar hata durumunda devralır. Partition başına bir leader, iki poller'ın aynı görevi dispatch etmesini önlerken, partitioning throughput'u yüksek tutar.
- **Ready queue (Kafka)**: due görevler kuyruğa eklenir, *scheduling*'i *execution*'dan decouple eder. Worker'lar poller'dan bağımsız ölçeklenir.
- **Idempotent worker**'lar çalıştırır ve **ack** eder. Teslimat at-least-once olduğundan, bir görev iki kez çalışabilir (poller dispatch'ten sonra, done işaretlemeden önce çöktü) — bu yüzden işin kendisi idempotent olmalı, `task_id` üzerinde anahtarlanmalı, yoksa bir müşteriden iki kez ücret alırsınız. Başarısızlıklar backoff ile yeniden denenir, sonra bir DLQ'ya iner.

## Mülakat perspektifi

Mülakatı yapan kişi iki şeyi yoklar: **verimli zaman lookup**'ı ve **exactly-once vs at-least-once**. "İyi", bir tablo üzerinde bir cron loop'tur; "harika", sorted-set index'i artı dağıtık exactly-once'ın pratik olmadığının dürüst kabulüdür, bu yüzden **at-least-once + idempotent worker**'ları seçersiniz. Klasik bir tuzak: tek bir scheduler node'una güvenmek — bu bir SPOF ve bir throughput tavanıdır. Bir diğeri: görevler saniye hassasiyeti gerektirirken çok kaba poll etmek (her dakika) veya çok ince poll edip store'u dövmek.

## Ödünleşimler ve hata

- **Hassasiyet vs yük**: 1s tick saniye seviyesi doğruluk verir ancak daha fazla poll; tarama maliyetini azaltmak için görevleri dakika başına sonra saniye başına alt kuyruklara bucket'layın (Kafka ve Quartz tarafından kullanılan "timing wheel" / hashed-wheel yaklaşımı).
- **At-least-once vs exactly-once**: bir çökme sınırı boyunca gerçek exactly-once elde edemezsiniz; idempotency key'leri çift execution'ı zararsız kılar — doğru ödünleşim.
- **Hata**: bir poller dispatch ortasında çökerse, leader election bir standby'ı terfi ettirir ve ack'lenmemiş görevler yeniden teslim edilir — hiçbir şey kaybolmaz, bazıları tekrarlanabilir. Node'lar arası **clock skew**'e dikkat edin (NTP) yoksa görevler erken/geç ateşlenir; ve yeniden denemeleri sınırlayın, böylece kalıcı olarak başarısız olan bir görev sonsuza kadar döngüye girmez — incelemek için DLQ'ya gönderin.

Mimari

Bileşenler ve akış

Mülakat perspektifi

Ödünleşimler ve hata

İlgili sorular