Hvordan køre du baggrundstasks med Celery?

Question

Accepted Answer

**Celery** er standardværktøjet til at køre **baggrundstasks og planlagte opgaver** i Django — arbejde, der ikke skal blokere HTTP-anmodningen (afsendelse af mails, behandling af filer, kald til langsomme API'er) eller som køres efter en plan. Tasks bliver sat i kø og behandlet asynkront af separate **worker**-processer.

## Det problem, som Celery løser

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

At udføre langsomt arbejde direkte får brugere til at vente og risikerer timeout af anmodningen. Celery aflaster det til baggrundworkers, så anmodningen returneres umiddelbart.

## Definition og kald af en Celery-task

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

Decoratoret `@shared_task` definerer en task; `.delay()` (eller `.apply_async()`) sætter den i kø til en worker for asynkron behandling — viewet venter ikke.

## Arkitekturen

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

## Planlagte / periodiske tasks (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
    },
}
```

## Pålideligheds-funktioner

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

## Hvorfor det betyder noget

Baggrundstask-behandling med Celery er vigtig viden til opbygning af responsive, skalerbare Django-applikationer, da mange virkelige behov kræver arbejde, der ikke bør foregå direkte under en anmodning.

Det er vigtigt at forstå, fordi kerneproblemét — at aflaste langsomt eller udskudt arbejde (afsendelse af mails, billedbehandling/filbehandling, generering af rapporter, kald til langsomme eksterne API'er, datasynkronisering) fra request-response-cyklussen — er allestedsnærværende i produktionsapplikationer.

At udføre sådant arbejde direkte får brugere til at vente, risikerer request timeouts og mister arbejdet, hvis det mislykkes, hvorimod **Celery** lader dig svare brugeren umiddelbart, mens separate **workers** behandler arbejdet asynkront og pålideligt.

Ud over simpel async-aflastning leverer Celery kritiske produktions-funktioner: **planlagte/periodiske tasks** (via Celery Beat, som erstatter cron for scheduling på applikationsniveau — daglige rapporter, oprydningsjobs, tilbagevendende synkroniseringer), **automatiske genforsøg med backoff** (modstandsdygtighed over for forbigående fejl), **task-persistering** (tasks i kø overlever genstarter via brokeren, så arbejde går ikke tabt), og **uafhængig skalering** af workers fra webservere.

At forstå Celerys arkitektur (brokeren som Redis/RabbitMQ, der holder køen, workers, der behandler tasks, result backend), hvordan man definerer og sætter tasks i kø (`@shared_task`, `.delay()`), planlægger periodisk arbejde, og konfigurerer pålideligheds-funktioner er værdifuld senior-level viden til opbygning af produktions Django-systemer, der håndterer tungt eller udskudt arbejde elegant.

Fordi baggrundbehandling er et almindeligt, vigtigt krav for responsive, robuste applikationer — og Celery er de facto standard-løsningen i Django-økosystemet — er det praktisk og hyppigt relevant at mestre den og reflekterer evnen til at arkitekturere virkelige Django-applikationer ud over simpel synkron request-handling.