Hur kör du bakgrundsuppgifter med Celery?

Question

Accepted Answer

**Celery** är standardverktyget för att köra **bakgrundsuppgifter och schemalagda uppgifter** i Django — arbete som inte bör blockera HTTP-begäran (skicka e-postmeddelanden, bearbeta filer, anropa långsamma API:er) eller som körs enligt ett schema. Uppgifter köas och bearbetas asynkront av separata **worker**-processer.

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

Att göra långsamt arbete inline gör att användare måste vänta och riskerar timeout för begäran. Celery överför det till bakgrundsworkers så att begäran returneras omedelbar.

## Definiering och anrop av en Celery-uppgift

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

Dekoratorn `@shared_task` definierar en uppgift; `.delay()` (eller `.apply_async()`) köar den för en worker att bearbeta asynkront — vyn väntar inte.

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

## Schemalagda / periodiska uppgifter (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
    },
}
```

## Tillförlitlighetsfunktioner

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

## Varför det spelar roll

Bearbetning av bakgrundsuppgifter med Celery är väsentlig kunskap för att bygga responsiva, skalbara Django-applikationer, eftersom många verkliga behov kräver arbete som inte bör ske inline under en begäran.

Det är viktigt att förstå eftersom kärnproblemet — att flytta långsamt eller uppskjutet arbete (skicka e-postmeddelanden, bearbeta bilder/filer, generera rapporter, anropa långsamma externa API:er, datasynkronisering) från request-response-cykeln — är överallt i produktionsapplikationer.

Att göra sådan arbete inline gör att användare måste vänta, riskerar timeout för begäran och förlorar arbetet om det misslyckas, medan **Celery** låter dig svara användaren omedelbar medan separata **workers** bearbetar arbetet asynkront och pålitligt.

Beyond simple async offloading, Celery provides critical production capabilities: **scheduled/periodic tasks** (via Celery Beat, replacing cron for application-level scheduling — daily reports, cleanup jobs, recurring syncs), **automatic retries with backoff** (resilience against transient failures), **task persistence** (queued tasks survive restarts via the broker, so work isn't lost), and **independent scaling** of workers from web servers.

Att förstå Celerys arkitektur (mäklaren som Redis/RabbitMQ som innehåller kön, workers som bearbetar uppgifter, resultatbackenden), hur man definierar och köar uppgifter (`@shared_task`, `.delay()`), schemalägg periodiskt arbete och konfigurerar tillförlitlighetsfunktioner är värdefull kunskap på senior-nivå för att bygga produktions-Django-system som hanterar tungt eller uppskjutet arbete på ett elegant sätt.

Eftersom bakgrundsbearbetning är ett vanligt, viktigt krav för responsiva, robusta applikationer — och Celery är de facto-standardlösningen i Django-ekosystemet — att bemästra det är en praktisk, ofta relevant skicklighet som reflekterar förmågan att arkitektera verkliga Django-applikationer bortom enkel synkron request-hantering.