Come si eseguono task in background con Celery?

Question

Accepted Answer

**Celery** è lo strumento standard per eseguire **task in background e programmati** in Django — lavoro che non dovrebbe bloccare la richiesta HTTP (invio email, elaborazione file, chiamate a API lente) o che viene eseguito secondo una pianificazione. I task vengono accodati ed elaborati in modo asincrono da processi **worker** separati.

## Il problema che Celery risolve

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

Eseguire lavoro lento inline fa aspettare gli utenti e rischia timeout della richiesta. Celery lo delega ai worker in background in modo che la richiesta ritorni immediatamente.

## Definire e chiamare un 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
```

Il decorator `@shared_task` definisce un task; `.delay()` (o `.apply_async()`) lo accoda affinché un worker lo elabori in modo asincrono — la view non aspetta.

## L'architettura

```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 programmati / periodici (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
    },
}
```

## Funzioni di affidabilità

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

## Perché è importante

L'elaborazione di task in background con Celery è una conoscenza essenziale per costruire applicazioni Django reattive e scalabili, poiché molte esigenze nel mondo reale richiedono lavoro che non dovrebbe accadere inline durante una richiesta.

Comprendere questo è importante perché il problema fondamentale — offloadare lavoro lento o differito (invio email, elaborazione immagini/file, generazione report, chiamate a API esterne lente, sincronizzazione dati) dal ciclo richiesta-risposta — è ubiquo nelle applicazioni in produzione.

Eseguire tale lavoro inline fa aspettare gli utenti, rischia timeout della richiesta e perde il lavoro se fallisce, mentre **Celery** ti permette di rispondere all'utente immediatamente mentre worker separati elaborano il lavoro in modo asincrono e affidabile.

Oltre al semplice offload asincrono, Celery fornisce capacità critiche per la produzione: **task programmati/periodici** (via Celery Beat, sostituendo cron per la pianificazione a livello applicativo — report giornalieri, job di pulizia, sincronizzazioni ricorrenti), **retry automatici con backoff** (resilienza contro fallimenti transitori), **persistenza dei task** (i task accodati sopravvivono ai riavvii via il broker, quindi il lavoro non viene perso), e **scaling indipendente** dei worker dai server web.

Comprendere l'architettura di Celery (il broker come Redis/RabbitMQ che tiene la coda, i worker che elaborano i task, il backend dei risultati), come definire e accodare task (`@shared_task`, `.delay()`), pianificare lavoro periodico, e configurare funzioni di affidabilità è una conoscenza di livello senior preziosa per costruire sistemi Django in produzione che gestiscono lavoro pesante o differito in modo elegante.

Poiché l'elaborazione in background è un requisito comune e importante per applicazioni reattive e robuste — e Celery è la soluzione de facto standard nell'ecosistema Django — padroneggiare questo è una skill pratica e frequentemente rilevante che riflette la capacità di progettare applicazioni Django nel mondo reale al di là della semplice gestione sincrona delle richieste.