Hvordan kjører du bakgrunnsoppgaver med Celery?

Question

Accepted Answer

**Celery** er standardverktøyet for å kjøre **bakgrunns- og planlagte oppgaver** i Django — arbeid som ikke bør blokkere HTTP-forespørselen (sending av e-poster, filbehandling, kall til langsomme APIer) eller som kjøres på en plan. Oppgaver plasseres i kø og behandles asynkront av separate **worker**-prosesser.

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

Å gjøre langsomt arbeid inline gjør at brukere må vente og risikerer forespørsels-timeout. Celery flytter det til bakgrunnsarbeidere slik at forespørselen returnerer umiddelbart.

## Definere og kalle en Celery-oppgave

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

`@shared_task`-dekoratøren definerer en oppgave; `.delay()` (eller `.apply_async()`) plasserer den i kø for at en worker skal behandle den asynkront — 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 oppgaver (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ålitelighetsfunksjoner

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

Bakgrunnsoppgavebehandling med Celery er essensiell kunnskap for å bygge responsive og skalerbare Django-applikasjoner, da mange virkelige behov krever arbeid som ikke bør skje inline under en forespørsel.

Å forstå det er viktig fordi kjerneproblem — å flytte langsomt eller utsatt arbeid (sending av e-poster, bildebehandling/filer, generering av rapporter, kall til langsomme eksterne APIer, datasynkronisering) fra request-response-syklusen — er allestedsnærværende i produksjonsprogrammer.

Å gjøre slikt arbeid inline gjør at brukere må vente, risikerer forespørsels-timeout og mister arbeidet hvis det mislykkes, mens **Celery** lar deg svare brukeren umiddelbart mens separate **workers** behandler arbeidet asynkront og pålitelig.

Utover enkel async-offloading gir Celery kritiske produksjonsfunksjoner: **planlagte/periodiske oppgaver** (via Celery Beat, som erstatter cron for planlegging på applikasjonsnivå — daglige rapporter, oppryddingsjobber, tilbakevendende synkroniseringer), **automatiske retrier med backoff** (motstand mot forbigående feil), **oppgavepersistens** (køde oppgaver overlever omstarter via broker, så arbeid går ikke tapt), og **uavhengig skalering** av workers fra webservere.

Å forstå Celerys arkitektur (broker som Redis/RabbitMQ som holder køen, workers som behandler oppgaver, result backend), hvordan man definerer og plasserer oppgaver i kø (`@shared_task`, `.delay()`), planlegger periodisk arbeid, og konfigurerer pålitelighetsfunksjoner er verdifull seniorkunnskaper for å bygge produksjon Django-systemer som håndterer tungt eller utsatt arbeid elegant.

Fordi bakgrunnsbehandling er et vanlig, viktig krav for responsive og robuste applikasjoner — og Celery er de facto standardløsningen i Django-økosystemet — er det å mestre det en praktisk, hyppig relevant ferdighet som reflekterer evnen til å arkitekturere virkelige Django-applikasjoner utover enkel synkron forespørselshåndtering.