તમે મજબૂત પૃષ્ઠભૂમિ કાર્યો (Celery/ARQ) કેવી રીતે ચલાવો છો?

Question

Accepted Answer

**મજબૂત, ટકાઉ પૃષ્ઠભૂમિ કાર્યો** (FastAPI ના હલકા વજન `BackgroundTasks` ની બહાર) માટે, તમે વાસ્તવિક કાર્ય કતાર વાપરો છો: **Celery** (સ્થાપિત ધોરણ) અથવા **ARQ** (આધુનિક async-native કતાર). આ ભારે, પુનઃપ્રયાસ કરી શકાય તેવા, શેડ્યુલ કરેલા કાર્યો અલગ worker પ્રક્રિયાઓમાં ચલાવે છે, Redis જેવા broker દ્વારા સમર્થિત.

## શું માત્ર 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
```

अंतઓપોઇન્ટ કાર્યને કતારમાં મૂકે છે અને તાત્ક્ષણિક પ્રતિક્રિયા આપે છે; એક અલગ **worker** પ્રક્રિયા તેને સ્થિરતા અને પુનઃપ્રયાસો સાથે ચલાવે છે.

## ARQ — async-native (FastAPI ના async મોડેલને બંધબેસે છે)

```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 એક હળવો, async-first વિકલ્પ છે — આકર્ષણીય જ્યારે તમારો કોડબેસ પહેલેથી async છે.

## વાસ્તવિક કાર્ય કતાર શું પ્રદાન કરે છે

```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** તરફ જવું જ્યારે કાર્ય ટકાઉ, પુનઃપ્રયાસ કરી શકાય તેવું, શેડ્યુલ કરેલું, ભારે, અથવા વિતરિત હોય (ફાઇલો/વિડિયો પ્રક્રિયા કરવી, થોક ઈમેલો મોકલવી, ડેટા સિંક્રોનાઈજ કરવું, રિપોર્ટ્સ જનરેટ કરવી).

આ કતારો નિર્ણાયક ઉત્પાદન ક્ષમતાઓ પ્રદાન કરે છે: **સ્થિરતા** (કાર્યો broker દ્વારા ક્રેશ થી બચે છે, તેથી કાર્ય ખોવાતું નથી), **સ્વચાલિત પુનઃપ્રયાસો** (અસ્થાયી નિષ્ફળતા માટે સ્થિતિસ્થાપકતા), **શેડ્યુલિંગ** (સામયિક કાર્યો), અને **independent scaling** web સર્વરોથી workers ના.

કાર્યો વ્યાખ્યાયિત અને કતારમાં મૂકવાનું (Celery ની `.delay()`, ARQ ની async-native API), આર્કિટેકચર (broker + workers), અને ખાસ કરીને વાસ્તવિક કતાર વિરુદ્ધ BackgroundTasks વાપરવાનો **નિર્ણય**, કેવી રીતે વિશ્વાસપૂર્ણ એપ્લિકેશનો બાંધવાનું તે જાણવું મૂલ્યવાન છે જે ભારે કાર્યોને ઓફલોડ કરે છે તેને ગુમાયા વિના — એક સામાન્ય, મહત્વપૂર્ણ આવશ્યકતા જે મજબૂત ઉત્પાદન પ્રણાલીઓને નાજુક તથી વિશ્વાસુ પ્રણાલીઓથી અલગ પાડે છે.