Kako poganjate naloge v ozadju z Celerjem?

Question

Accepted Answer

**Celery** je standardno orodje za poganjanje **nalog v ozadju in načrtovanih nalog** v Djangu — delo, ki ne sme blokirati HTTP zahtevka (pošiljanje e-pošte, obdelava datotek, klici počasnih API-jev) ali delo, ki se izvaja po urniku. Naloge se čakajo v vrsti in jih asinkrono obdelujejo ločeni **worker** procesi.

## Problem, ki ga Celery rešuje

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

Počasno delo, izvršeno vstaviti, prisili uporabnike, da čakajo in tvega časovne limite zahtevkov. Celery ga prenese na delavce v ozadju, tako da se zahtevek takoj vrne.

## Opredeljevanje in klicanje Celery naloge

```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` opredeli nalogo; `.delay()` (ali `.apply_async()`) jo postavi v vrsto za obdelavo delavca asinkrono — pogled ne čaka.

## Arhitektura

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

## Načrtovane / periodične naloge (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
    },
}
```

## Značilnosti zanesljivosti

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

## Zakaj je to pomembno

Obdelava nalog v ozadju z Celerjem je bistveno znanje za izgradnjo odzivnih, razširljivih Django aplikacij, saj mnoge pravi potrebe zahtevajo delo, ki se ne sme zgoditi vstaviti med zahtevek.

Razumevanje je pomembno, ker je osnovna težava — prenašanje počasnega ali odloženega dela (pošiljanje e-pošte, obdelava slik/datotek, ustvarjanje poročil, klici počasnih zunanjih API-jev, sinhronizacija podatkov) iz cikla zahtevek-odgovor — povsod v proizvodnih aplikacijah.

Počasno delo, izvršeno vstaviti, prisili uporabnike, da čakajo, tvega časovne limite zahtevkov in izgubi delo, če ne uspe, medtem ko vam **Celery** omogoča, da se odzovete uporabniku takoj, medtem ko ločeni **workers** asinkrono in zanesljivo obdelujejo delo.

Poleg enostavnega asinkronega prenašanja Celery zagotavlja kritične zmogljivosti produkcije: **načrtovane/periodične naloge** (prek Celery Beat, ki nadomešča cron za načrtovanje na ravni aplikacije — dnevna poročila, dela čiščenja, periodične sinhronizacije), **avtomatske ponovne poskuse z umikom** (odpornost na prehodno neuspešne), **trajnost nalog** (naloge v vrsti preživi ponovne zagon prek posrednika, zato delo ni izgubljeno) in **neodvisno skaliranje** delavcev od spletnih strežnikov.

Razumevanje Celery arhitekture (posrednik, kot je Redis/RabbitMQ, ki drži vrsto, delavci, ki obdelujejo naloge, rezultat backend), kako opredeliti in postaviti naloge v vrsto (`@shared_task`, `.delay()`), načrtovati periodično delo in konfigurirati značilnosti zanesljivosti, je dragoceno znanje na višji ravni za izgradnjo proizvodnih Django sistemov, ki elegantno obdelujejo težko ali odloženo delo.

Ker je obdelava v ozadju pogosta in važna zahteva za odzivne, robustne aplikacije — in je Celery de facto standarden rešitev v ekosistemu Django — je obvladovanje tega praktično, pogosto relevantna veščina, ki odraža zmožnost oblikovanja aplikacij Django v resničnem svetu, ki presegajo preprosto sinhrono obdelavo zahtevkov.