كيف تقوم بتشغيل وظائف خلفية قوية وموثوقة (Celery/ARQ)؟

Question

Accepted Answer

للحصول على **وظائف خلفية قوية وموثوقة** (تتجاوز `BackgroundTasks` الخفيفة الوزن في FastAPI)، تستخدم طابور مهام حقيقي: **Celery** (المعيار الراسخ) أو **ARQ** (طابور غير متزامن حديث). تعمل هذه على تنفيذ العمل الثقيل والقابل لإعادة المحاولة والمجدول في عمليات عامل منفصلة، مدعومة بوسيط مثل Redis.

## لماذا لا نستخدم فقط BackgroundTasks؟

```text
BackgroundTasks runs in the web process → NO persistence (lost on crash), NO retries,
NO scheduling, and heavy work ties up the worker. Fine only for quick fire-and-forget.
For durable/critical/heavy/scheduled jobs → use a real task queue (Celery / ARQ).
```

## Celery — تعريف وإدراج المهام في الطابور

```python
# tasks.py
from celery import Celery
celery_app = Celery("tasks", broker="redis://localhost:6379")

@celery_app.task(bind=True, max_retries=3)
def process_video(self, video_id: int):
    try:
        do_heavy_processing(video_id)        # runs in a WORKER, not the web process
    except Exception as exc:
        raise self.retry(exc=exc, countdown=60)   # automatic retry on failure
```

```python
# in a FastAPI endpoint — QUEUE the task, return immediately
@app.post("/videos/{id}/process")
def process(id: int):
    process_video.delay(id)                  # enqueue → returns at once (doesn't block)
    return {"status": "processing started"}
# run workers separately: celery -A tasks worker
```

نقطة النهاية تدرج المهمة في الطابور وتستجيب على الفور؛ عملية **عامل** منفصلة تنفذها مع الاستمرارية وإعادة المحاولات.

## ARQ — غير متزامن أصلي (يناسب نموذج FastAPI غير المتزامن)

```python
# ARQ is built on asyncio — a natural fit for async FastAPI codebases
async def process_video(ctx, video_id: int):
    await do_async_processing(video_id)

# enqueue from an endpoint
await redis.enqueue_job("process_video", video_id)
```

ARQ هو بديل أخف وزناً وموجه نحو عدم التزامن — جذاب عندما تكون قاعدة الأكوار الخاصة بك بالفعل غير متزامنة.

## ما الذي يوفره طابور مهام حقيقي

```text
✓ Persistence — jobs survive crashes/restarts (stored in the broker)
✓ Retries with backoff — resilience against transient failures
✓ Scheduling — periodic/cron-like jobs (Celery Beat)
✓ Distribution & scaling — workers scale independently of the web servers
✓ Concurrency & rate limiting, task routing/priorities, result tracking
```

## لماذا هذا مهم

تشغيل وظائف خلفية قوية أمر ضروري لبناء تطبيقات FastAPI على مستوى الإنتاج تتعامل مع العمل الثقيل أو المؤجل بشكل موثوق — وفهم متى وكيفية استخدام طابور مهام حقيقي هو معرفة مهمة على مستوى أعلى.

الحكم الأساسي هو التعرف على **حدود `BackgroundTasks`** (لا توجد استمرارية أو إعادة محاولات أو جدولة — مقبول فقط للعمل السريع وغير الحرج) والالتجاء إلى **Celery أو ARQ** عندما يجب أن يكون العمل موثوقاً أو قابلاً لإعادة المحاولة أو مجدولاً أو ثقيلاً أو موزعاً (معالجة الملفات/مقاطع الفيديو، إرسال رسائل بريد إلكترونية جماعية، مزامنة البيانات، إنشاء التقارير).

توفر هذه الطوابير قدرات إنتاجية حرجة: **الاستمرارية** (تبقى المهام حية عند الأعطال عبر الوسيط، لذا لا يتم فقدان العمل)، **إعادة محاولات تلقائية** (المتانة ضد الأعطال العابرة)، **الجدولة** (المهام الدورية)، و**التوسع المستقل** للعمال عن خوادم الويب.

معرفة كيفية تعريف وإدراج المهام في الطابور (`.delay()` في Celery، API غير المتزامن الأصلي في ARQ)، والعمارة (الوسيط + العمال)، والأهم من ذلك، **قرار متى يتم استخدام طابور حقيقي مقابل BackgroundTasks**، قيمة لإنشاء نظام معماري لتطبيقات موثوقة تفرغ العمل الثقيل دون فقدانه — وهي متطلبة شائعة ومهمة تميز الأنظمة الإنتاجية القوية عن الأنظمة الهشة.