Hogyan futtathat robosztus háttérfeladatokat (Celery/ARQ)?

Question

Accepted Answer

A **robosztus, tartós háttérfeladatokhoz** (amely túlmegy a FastAPI könnyű `BackgroundTasks` megoldásán) egy valódi feladatsor-kezelőt használ: **Celery** (az etablált standard) vagy **ARQ** (egy modern aszinkron natív sor). Ezek nehéz, újrapróbálható, ütemezett munkákat futtatnak külön worker folyamatokban, egy olyan broker (például Redis) által támogatva.

## Miért ne csak a BackgroundTasks?

```text
BackgroundTasks runs in the web process → NO persistence (lost on crash), NO retries,
NO scheduling, and heavy work ties up the worker. Fine only for quick fire-and-forget.
For durable/critical/heavy/scheduled jobs → use a real task queue (Celery / ARQ).
```

## Celery — feladatok definiálása és üzenetsorba helyezése

```python
# tasks.py
from celery import Celery
celery_app = Celery("tasks", broker="redis://localhost:6379")

@celery_app.task(bind=True, max_retries=3)
def process_video(self, video_id: int):
    try:
        do_heavy_processing(video_id)        # runs in a WORKER, not the web process
    except Exception as exc:
        raise self.retry(exc=exc, countdown=60)   # automatic retry on failure
```

```python
# in a FastAPI endpoint — QUEUE the task, return immediately
@app.post("/videos/{id}/process")
def process(id: int):
    process_video.delay(id)                  # enqueue → returns at once (doesn't block)
    return {"status": "processing started"}
# run workers separately: celery -A tasks worker
```

A végpont sorba helyezi a feladatot és azonnal válaszol; egy külön **worker** folyamat hajtja végre azt perzisztenciával és újrapróbálkozásokkal.

## ARQ — aszinkron natív (illeszkedik FastAPI aszinkron modelljéhez)

```python
# ARQ is built on asyncio — a natural fit for async FastAPI codebases
async def process_video(ctx, video_id: int):
    await do_async_processing(video_id)

# enqueue from an endpoint
await redis.enqueue_job("process_video", video_id)
```

Az ARQ egy könnyebb, aszinkron-first alternatíva — vonzó, amikor a kódbázis már aszinkron.

## Mit nyújt egy valódi feladatsor

```text
✓ Persistence — jobs survive crashes/restarts (stored in the broker)
✓ Retries with backoff — resilience against transient failures
✓ Scheduling — periodic/cron-like jobs (Celery Beat)
✓ Distribution & scaling — workers scale independently of the web servers
✓ Concurrency & rate limiting, task routing/priorities, result tracking
```

## Miért fontos

A robosztus háttérfeladatok futtatása alapvető a termelési szintű FastAPI alkalmazások építéséhez, amelyek megbízhatóan kezelik a nehéz vagy elhalasztott munkákat — és annak megértése, hogy mikor és hogyan kell valódi feladatsort használni, fontos senior szintű tudás.

Az alapvető ítéletalkotás a **`BackgroundTasks` korlátainak** (nincs perzisztencia, újrapróbálkozás vagy ütemezés — csak gyors, nem kritikus munka esetén megfelelő) felismerése és **Celery vagy ARQ** alkalmazása, amikor a munka tartós, újrapróbálható, ütemezett, nehéz vagy elosztott (fájlok/videók feldolgozása, tömeges e-mailek küldése, adatszinkronizálás, jelentések generálása).

Ezek a sorok kritikus termelési képességeket biztosítanak: **perzisztencia** (a feladatok a broker által történő összeomláson túlélnek, így a munka nem veszik el), **automatikus újrapróbálkozások** (reziliencia az átmeneti hibák ellen), **ütemezés** (periodikus feladatok) és a **worker és webkiszolgálók független skálázása**.

Annak ismerete, hogyan kell feladatokat definiálni és sorba helyezni (Celery `.delay()` metódusa, ARQ aszinkron natív API-ja), az architektúra (broker + worker-ek) és különösen az **amikor valódi sor kontra BackgroundTasks használata szükséges**, értékes a megbízható alkalmazások tervezéséhez, amelyek nehéz munkákat offloadálnak anélkül, hogy elveszítenék — egy gyakori, fontos követelmény, amely megkülönbözteti az erős termelési rendszereket a törékenyek közül.