10M நேரமிடப்பட்ட tasks-க்கான ஒரு scheduler-ஐ எப்படி வடிவமைப்பீர்கள்?

Question

IT Interview Practice · Accepted Answer

due time-ஆல் keyed செய்யப்பட்ட ஒரு **time-bucketed / priority queue**-இல் tasks-ஐச் சேமியுங்கள், *இப்போது* due ஆகும் tasks-ஐ மட்டும் poll செய்யுங்கள், மேலும் **at-least-once** delivery உடன் idempotent workers-க்கு அவற்றைக் கொடுங்கள். ஒவ்வொரு tick-இலும் 10M rows-ஐ ஒருபோதும் scan செய்யாதீர்கள் — fire time-ஆல் index செய்யுங்கள், இதனால் ஒவ்வொரு poll-ம் due ஆனதை மட்டும் தொடுகிறது.

## கட்டமைப்பு

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

## கூறுகளும் ஓட்டமும்

- **fire time-ஆல் index செய்யப்பட்ட Task store**: ஒரு Redis sorted set (`ZADD tasks score=due_ts`) அல்லது `(run_at)` மீது index செய்யப்பட்ட ஒரு DB table. `ZPOPMIN`/`ZRANGEBYSCORE now` இந்த வினாடி due ஆகும் tasks-ஐ மட்டும் pull செய்கிறது — O(log n), table scan அல்ல. task-id-ஆல் **Sharding/partitioning** 10M tasks-ஐ nodes முழுவதும் பரப்புகிறது, இதனால் ஒரு single store hot ஆகாது.
- **leader election உடன் Poller**: ஒவ்வொரு partition-க்கும் etcd/ZooKeeper மூலம் தேர்ந்தெடுக்கப்பட்ட ஒரு active poller உண்டு; தோல்வியில் standbys ஏற்றுக்கொள்கின்றன. ஒரு partition-க்கு ஒரு leader இரண்டு pollers ஒரே task-ஐ dispatch செய்வதைத் தவிர்க்கிறது, அதே நேரம் partitioning throughput-ஐ உயர்வாக வைக்கிறது.
- **Ready queue (Kafka)**: due tasks enqueue செய்யப்படுகின்றன, *scheduling*-ஐ *execution*-இலிருந்து decouple செய்கின்றன. Workers poller-ஐ சார்ந்து இல்லாமல் அளவிடுகின்றன.
- **Idempotent workers** execute செய்து **ack** செய்கின்றன. delivery at-least-once என்பதால், ஒரு task இருமுறை இயங்கலாம் (dispatch-க்குப் பிறகு, done என்று மதிப்பிடும் முன் poller crash ஆனது) — எனவே வேலையே idempotent-ஆக, `task_id` மீது keyed செய்யப்பட்டதாக இருக்க வேண்டும், இல்லையெனில் ஒரு customer-ஐ இரட்டை charge செய்கிறீர்கள். தோல்விகள் backoff உடன் retry செய்து, பிறகு ஒரு DLQ-இல் விழுகின்றன.

## நேர்காணல் கண்ணோட்டம்

நேர்காணல் செய்பவர் இரண்டை ஆராய்கிறார்: **efficient time lookup** மற்றும் **exactly-once vs at-least-once**. "நல்லது" என்பது ஒரு table மீது ஒரு cron loop; "சிறந்தது" என்பது sorted-set index மற்றும் distributed exactly-once நடைமுறைக்கு சாத்தியமற்றது என்ற நேர்மையான ஒப்புதல், எனவே நீங்கள் **at-least-once + idempotent workers** தேர்ந்தெடுக்கிறீர்கள். ஒரு classic பொறி: ஒரே scheduler node-ஐ நம்புவது — அது ஒரு SPOF மற்றும் ஒரு throughput உச்சவரம்பு. மற்றொன்று: tasks-க்கு second precision தேவைப்படும்போது மிகவும் coarse-ஆக (ஒவ்வொரு நிமிடமும்) poll செய்வது, அல்லது மிகவும் fine-ஆக store-ஐ அடித்து நொறுக்குவது.

## சமரசங்களும் தோல்வியும்

- **Precision vs load**: 1s tick second-level accuracy தருகிறது ஆனால் அதிக polls; scan cost-ஐக் குறைக்க tasks-ஐ per-minute பிறகு per-second sub-queues-ஆக bucket செய்யுங்கள் (Kafka மற்றும் Quartz பயன்படுத்தும் "timing wheel" / hashed-wheel அணுகுமுறை).
- **At-least-once vs exactly-once**: ஒரு crash boundary முழுவதும் உண்மையான exactly-once பெற முடியாது; idempotency keys இரட்டை execution-ஐ தீங்கற்றதாக்குகின்றன — சரியான trade.
- **தோல்வி**: ஒரு poller dispatch நடுவில் இறந்தால், leader election ஒரு standby-ஐ promote செய்து un-acked tasks redeliver ஆகின்றன — எதுவும் இழக்கப்படவில்லை, சில மீண்டும் நடக்கலாம். nodes முழுவதும் **clock skew**-ஐ (NTP) கவனியுங்கள் இல்லையெனில் tasks சீக்கிரம்/தாமதமாக fire ஆகும்; மேலும் retries-ஐ cap செய்யுங்கள், இதனால் நிரந்தரமாகத் தோல்வியுறும் ஒரு task எப்போதும் loop செய்யாது — பரிசோதனைக்கு அதை DLQ-க்கு அனுப்புங்கள்.

கட்டமைப்பு

கூறுகளும் ஓட்டமும்

நேர்காணல் கண்ணோட்டம்

சமரசங்களும் தோல்வியும்

தொடர்புடைய கேள்விகள்