Wie führen Sie Hintergrundaufgaben mit Celery aus?

Question

IT Interview Practice · Accepted Answer

**Celery** ist das Standard-Tool zum Ausführen von **Hintergrund- und geplanten Aufgaben** in Django — Arbeit, die die HTTP-Anfrage nicht blockieren sollte (E-Mails versenden, Dateien verarbeiten, langsame APIs aufrufen) oder nach einem Zeitplan ausgeführt wird. Aufgaben werden in die Warteschlange gestellt und asynchron von separaten **Worker**-Prozessen verarbeitet.

## Das Problem, das Celery löst

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

Langsame Arbeit inline auszuführen lässt Benutzer warten und riskiert Request-Timeouts. Celery verlagert sie auf Background-Worker, sodass die Anfrage sofort zurückkommt.

## Definieren und Aufrufen einer Celery-Aufgabe

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

Der `@shared_task`-Decorator definiert eine Aufgabe; `.delay()` (oder `.apply_async()`) stellt sie in die Warteschlange für asynchrone Verarbeitung durch einen Worker — die View wartet nicht.

## Die Architektur

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

## Geplante / periodische Aufgaben (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
    },
}
```

## Zuverlässigkeitsfunktionen

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

## Warum es wichtig ist

Hintergrundaufgabenverarbeitung mit Celery ist wesentlich für den Aufbau responsiver, skalierbarer Django-Anwendungen, da viele reale Anforderungen Arbeit erfordern, die nicht inline während einer Anfrage stattfinden sollte.

Das Verständnis ist wichtig, da das Kernproblem — das Auslagern von langsamer oder aufgeschobener Arbeit (E-Mails versenden, Bilder/Dateien verarbeiten, Berichte generieren, langsame externe APIs aufrufen, Datensynchronisierung) aus dem Request-Response-Zyklus — in Produktionsanwendungen allgegenwärtig ist.

Solche Arbeit inline auszuführen lässt Benutzer warten, riskiert Request-Timeouts und verliert die Arbeit, wenn sie fehlschlägt, während **Celery** dem Benutzer sofort antworten lässt, während separate **Worker** die Arbeit asynchron und zuverlässig verarbeiten.

Über einfaches asynchrones Auslagern hinaus bietet Celery kritische Produktionsfunktionen: **geplante/periodische Aufgaben** (über Celery Beat, ersetzt cron für Anwendungsplanung — tägliche Berichte, Bereinigungsjobs, wiederkehrende Syncs), **automatische Wiederholungen mit Backoff** (Widerstandsfähigkeit gegen vorübergehende Ausfälle), **Task-Persistierung** (warteschlangierte Aufgaben überleben Neustarts über den Broker, sodass Arbeit nicht verloren geht), und **unabhängige Skalierung** von Workern von Web-Servern.

Das Verständnis der Celery-Architektur (der Broker wie Redis/RabbitMQ, der die Warteschlange hält, Worker, die Aufgaben verarbeiten, das Result-Backend), wie man Aufgaben definiert und in die Warteschlange stellt (`@shared_task`, `.delay()`), periodische Arbeit plant und Zuverlässigkeitsfunktionen konfiguriert, ist wertvolleres Senior-Level-Wissen zum Aufbau von Produktions-Django-Systemen, die schwere oder aufgeschobene Arbeit elegant bewältigen.

Da Hintergrundverarbeitung eine häufige, wichtige Anforderung für responsive, robuste Anwendungen ist — und Celery die De-facto-Standard-Lösung im Django-Ökosystem ist — ist die Beherrschung davon eine praktische, häufig relevante Fähigkeit, die die Fähigkeit widerspiegelt, reale Django-Anwendungen über einfache synchrone Request-Bearbeitung hinaus zu architekturieren.

Das Problem, das Celery löst

Definieren und Aufrufen einer Celery-Aufgabe

Die Architektur

Geplante / periodische Aufgaben (Celery Beat)

Zuverlässigkeitsfunktionen

Warum es wichtig ist

Ähnliche Fragen