كيف تصمّم مجدولاً (scheduler) لعشرة ملايين مهمة مؤقّتة؟

Question

IT Interview Practice · Accepted Answer

خزّن المهام في **طابور موزّع زمنياً / حسب الأولوية (time-bucketed / priority queue)** مُفهرَس بوقت الاستحقاق، واستطلع فقط المهام المستحقّة *الآن*، وسلّمها إلى عمّال idempotent بتسليم **at-least-once**. لا تمسح أبداً عشرة ملايين صفّ في كل نبضة (tick) — افهرِس حسب وقت الإطلاق كي تلمس كل عملية استطلاع ما استحقّ فقط.

## البنية المعمارية

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

## المكونات وسير العمل

- **مخزن المهام المُفهرَس بوقت الإطلاق**: مجموعة مرتّبة في Redis (`ZADD tasks score=due_ts`) أو جدول قاعدة بيانات مُفهرَس على `(run_at)`. `ZPOPMIN`/`ZRANGEBYSCORE now` تسحب فقط المهام المستحقّة هذه الثانية — بتعقيد O(log n)، لا مسح جدول. **التجزئة (Sharding/partitioning)** حسب معرّف المهمة توزّع العشرة ملايين مهمة على العُقد كي لا يكون أي مخزن ساخناً.
- **مستطلِع مع انتخاب قائد (leader election)**: كل جزء (partition) له مستطلِع نشط واحد يُنتخب عبر etcd/ZooKeeper؛ تتولّى الاحتياطيات المهمة عند الفشل. قائد واحد لكل جزء يمنع مستطلعَين من إرسال المهمة نفسها، بينما تُبقي التجزئة الـ throughput مرتفعاً.
- **طابور الجاهزية (Ready queue) (Kafka)**: تُوضع المهام المستحقّة في الطابور، ففُصل *الجدولة* عن *التنفيذ*. يتوسّع العمّال بشكل مستقل عن المستطلِع.
- **عمّال idempotent** ينفّذون ويُقرّون (**ack**). ولأن التسليم at-least-once، قد تُنفَّذ المهمة مرتين (انهار المستطلِع بعد الإرسال قبل وسمها منجَزة) — فيجب أن يكون العمل نفسه idempotent، مُفهرساً على `task_id`، وإلا حصّلت من العميل مرتين. تُعاد محاولة الإخفاقات بتراجع، ثم تنتهي في DLQ.

## منظور المقابلة

يتحرّى المُحاور أمرين: **البحث الزمني الفعّال** و**exactly-once مقابل at-least-once**. "الجيد" هو حلقة cron على جدول؛ و"الرائع" هو فهرس المجموعة المرتّبة مع الاعتراف الصادق بأن exactly-once الموزّع غير عملي، فتختار **at-least-once + عمّال idempotent**. فخّ كلاسيكي: الاعتماد على عقدة مجدول واحدة — فهي نقطة فشل وحيدة (SPOF) وسقف للـ throughput. وآخر: الاستطلاع بخشونة زائدة (كل دقيقة) بينما المهام تحتاج دقّة الثانية، أو بدقّة زائدة فتُرهِق المخزن.

## المقايضات والأعطال

- **الدقّة مقابل الحمل**: نبضة كل ثانية تعطي دقّة على مستوى الثانية لكن استطلاعات أكثر؛ وزّع المهام في طوابير فرعية لكل دقيقة ثم لكل ثانية لتقليل تكلفة المسح (أسلوب "العجلة الزمنية" / hashed-wheel المستخدَم في Kafka وQuartz).
- **At-least-once مقابل exactly-once**: لا يمكنك تحقيق exactly-once حقيقي عبر حدّ الانهيار (crash boundary)؛ مفاتيح idempotency تجعل التنفيذ المزدوج غير ضارّ — وهي المقايضة الصحيحة.
- **العطل**: إن مات مستطلِع في منتصف الإرسال، يرفع الانتخاب احتياطياً وتُعاد المهام غير المُقرّة — لا يُفقد شيء، وقد يتكرّر بعضها. راقب **انحراف الساعة (clock skew)** عبر العُقد (NTP) وإلا انطلقت المهام مبكّراً/متأخّراً؛ وحُدّ إعادات المحاولة كي لا تدور مهمة فاشلة دائماً إلى الأبد — أرسلها إلى DLQ للفحص.

البنية المعمارية

المكونات وسير العمل

منظور المقابلة

المقايضات والأعطال

أسئلة ذات صلة