Cum rulezi task-uri în fundal cu Celery?

Question

Accepted Answer

**Celery** este instrumentul standard pentru rularea **task-urilor din fundal și planificate** în Django — lucrări care nu ar trebui să blocheze cererea HTTP (trimiterea de emailuri, procesarea fișierelor, apelarea de API-uri lente) sau care se execută conform unui program. Task-urile sunt puse în coadă și procesate asincron de procese separate de **worker**.

## Problema pe care o rezolvă Celery

```python
# ❌ doing slow work inline blocks the response — the user waits, risks timeouts
def register(request):
    user = create_user(request.POST)
    send_welcome_email(user)           # slow — the user waits for the email to send
    generate_report(user)               # even slower
    return redirect("home")             # finally responds after all that
```

Facerea lucrării lente inline îi forțează pe utilizatori să aștepte și riscă timeout-uri de cereri. Celery o descarcă pe worker-ii din fundal, deci cererea se întoarce imediat.

## Definirea și apelarea unui task Celery

```python
# tasks.py — define a task
from celery import shared_task

@shared_task
def send_welcome_email(user_id):
    user = User.objects.get(id=user_id)
    send_email(user.email, "Welcome!")    # runs in a WORKER, not the web process

# in a view — QUEUE the task instead of running it inline
def register(request):
    user = create_user(request.POST)
    send_welcome_email.delay(user.id)     # .delay() queues it → returns IMMEDIATELY
    return redirect("home")                # user gets a fast response
```

Decoratorul `@shared_task` definește un task; `.delay()` (sau `.apply_async()`) îl pune în coadă pentru ca un worker să îl proceseze asincron — view-ul nu așteaptă.

## Arhitectura

```text
Django (web) --.delay()--> BROKER (Redis/RabbitMQ) --> CELERY WORKER (processes the task)
                              (the message queue)         (separate process/machine)
```

```text
Components:
  ✓ Broker (Redis or RabbitMQ) — holds the queue of pending tasks
  ✓ Celery worker(s) — separate processes that pull and execute tasks
  ✓ Result backend (optional) — stores task results/status
Run workers separately: `celery -A myproject worker`
```

## Task-uri planificate / periodice (Celery Beat)

```python
# run tasks on a schedule (like cron) via Celery Beat
CELERY_BEAT_SCHEDULE = {
    "daily-report": {
        "task": "myapp.tasks.generate_daily_report",
        "schedule": crontab(hour=0, minute=0),     # every midnight
    },
}
```

## Funcții de fiabilitate

```python
@shared_task(bind=True, max_retries=3, default_retry_delay=60)
def sync_data(self):
    try:
        do_sync()
    except Exception as exc:
        raise self.retry(exc=exc)             # automatic retries on failure
```

```text
✓ Retries with backoff (resilience against transient failures)
✓ Task persistence (queued tasks survive restarts via the broker)
✓ Scheduling (Celery Beat — periodic/cron-like tasks)
✓ Rate limiting, concurrency control, task routing/priorities
✓ Workers scale independently of web servers
```

## De ce este important

Procesarea task-urilor din fundal cu Celery este cunoaștere esențială pentru construirea de aplicații Django responsabile și scalabile, deoarece multe nevoi din lumea reală necesită lucru care nu ar trebui să se întâmple inline în timpul unei cereri.

Înțelegerea acestuia este importantă deoarece problema de bază — descărcarea lucrării lente sau amânate (trimiterea de emailuri, procesarea imaginilor/fișierelor, generarea de rapoarte, apelarea de API-uri externe lente, sincronizarea datelor) din ciclul cerere-răspuns — este omniprezentă în aplicațiile de producție.

Facerea unei astfel de lucrări inline forțează utilizatorii să aștepte, riscă timeout-uri de cereri și pierde lucrarea dacă eșuează, în timp ce **Celery** îți permite să răspunzi utilizatorului imediat, iar **worker-ii** separați procesează lucrarea asincron și fiabil.

Dincolo de descărcarea asincronă simplă, Celery oferă capacități critice de producție: **task-uri planificate/periodice** (prin Celery Beat, înlocuind cron pentru planificarea la nivel de aplicație — rapoarte zilnice, job-uri de curățare, sincronizări recurente), **reîncercări automate cu backoff** (reziliență împotriva eșecurilor tranzitorii), **persistența task-urilor** (task-urile puse în coadă supraviețuiesc restarturi prin broker, deci lucrarea nu se pierde) și **scalarea independentă** a worker-ilor de la servere web.

Înțelegerea arhitecturii Celery (brokerul ca Redis/RabbitMQ care ține coada, worker-ii care procesează task-uri, backend-ul de rezultate), cum să definești și să pui în coadă task-uri (`@shared_task`, `.delay()`), planificarea lucrării periodice și configurarea funcțiilor de fiabilitate este cunoaștere valoroasă de nivel senior pentru construirea sistemelor Django de producție care gestionează lucrări grele sau amânate cu ușurință.

Deoarece procesarea în fundal este o cerință comună și importantă pentru aplicațiile responsabile și robuste — și Celery este soluția de facto în ecosistemul Django — stăpânirea acesteia este o abilitate practică, frecvent relevantă care reflectă capacitatea de a proiecta aplicații Django din lumea reală dincolo de manipularea sincronă simplă a cererilor.