Jak uruchamiać zadania w tle za pomocą Celery?

Question

Accepted Answer

**Celery** jest standardowym narzędziem do uruchamiania **zadań w tle i zaplanowanych** w Django — pracy, która nie powinna blokować żądania HTTP (wysyłanie e-maili, przetwarzanie plików, wywoływanie wolnych API) lub pracy wykonującej się zgodnie z harmonogramem. Zadania są kolejkowane i przetwarzane asynchronicznie przez oddzielne procesy **worker**.

## Dlaczego to ważne

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

Wykonywanie wolnej pracy w linii powoduje, że użytkownicy czekają i ryzykuje przekroczenie limitu czasu żądania. Celery przenosi ją do pracowników w tle, aby żądanie wróciło natychmiast.

## Definiowanie i wywoływanie zadania 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
```

Dekorator `@shared_task` definiuje zadanie; `.delay()` (lub `.apply_async()`) kolejkuje je do przetworzenia przez pracownika asynchronicznie — widok nie czeka.

## Architektura

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

## Zaplanowane / okresowe zadania (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
    },
}
```

## Funkcje niezawodności

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

## Dlaczego to ważne

Przetwarzanie zadań w tle za pomocą Celery jest istotną wiedzą do budowania responsywnych, skalowalnych aplikacji Django, ponieważ wiele rzeczywistych potrzeb wymaga pracy, która nie powinna odbywać się w linii podczas żądania.

Zrozumienie tego jest ważne, ponieważ problem podstawowy — przesunięcie wolnej lub odroczonej pracy (wysyłanie e-maili, przetwarzanie obrazów/plików, generowanie raportów, wywoływanie wolnych zewnętrznych API, synchronizacja danych) z cyklu żądania-odpowiedzi — jest wszechobecne w aplikacjach produkcyjnych.

Wykonywanie takiej pracy w linii powoduje, że użytkownicy czekają, ryzykuje przekroczenie limitu czasu żądania i traci pracę, jeśli się nie powiedzie, natomiast **Celery** pozwala natychmiast odpowiedzieć użytkownikowi, podczas gdy oddzielni **pracownicy** przetwarzają pracę asynchronicznie i niezawodnie.

Poza prostym offloadingiem asynchronicznym, Celery zapewnia krytyczne możliwości produkcyjne: **zaplanowane/okresowe zadania** (via Celery Beat, zastępując cron dla planowania na poziomie aplikacji — codzienne raporty, zadania czyszczenia, cykliczne synchronizacje), **automatyczne ponowne próby z backoffem** (odporność na przejściowe błędy), **trwałość zadań** (kolejkowane zadania przetrwają ponowne uruchomienia poprzez brokera, więc praca nie zostanie utracona) i **niezależne skalowanie** pracowników od serwerów sieciowych.

Zrozumienie architektury Celery (broker taki jak Redis/RabbitMQ przechowujący kolejkę, pracownicy przetwarzający zadania, backend wyników), jak definiować i kolejkować zadania (`@shared_task`, `.delay()`), planować pracę okresową i konfigurować funkcje niezawodności jest cenną wiedzą na poziomie seniorskim do budowania produkcyjnych systemów Django, które elegancko obsługują ciężką lub odroczoną pracę.

Ponieważ przetwarzanie w tle jest powszechnym, ważnym wymogiem dla responsywnych, solidnych aplikacji — a Celery jest de facto standardowym rozwiązaniem w ekosystemie Django — opanowanie go jest praktyczną, często istotną umiejętnością, która odzwierciedla zdolność do projektowania rzeczywistych aplikacji Django poza prostym synchronicznym obsługiwaniem żądań.