Jak uruchamiać niezawodne zadania w tle (Celery/ARQ)?

Question

Accepted Answer

Dla **niezawodnych, trwałych zadań w tle** (poza lekką funkcją `BackgroundTasks` w FastAPI) używasz prawdziwej kolejki zadań: **Celery** (ustanowiony standard) lub **ARQ** (nowoczesna kolejka natywna dla async). Są one uruchamiane w oddzielnych procesach roboczych, obsługiwane przez brokera, takiego jak Redis, z obsługą ciężkich, powtarzalnych i zaplanowanych prac.

## Dlaczego to ważne

```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 — definiuj i kolejkuj zadania

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

Endpoint enqueue'uje zadanie i odpowiada natychmiast; osobny proces **worker** wykonuje je z trwałością i ponowными próbami.

## ARQ — natywny dla async (pasuje do modelu async FastAPI)

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

ARQ to lżejsza, asynchroniczna alternatywa — atrakcyjna, gdy Twoja baza kodu jest już asynchroniczna.

## Co zapewnia prawdziwa kolejka zadań

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

## Dlaczego to ważne

Uruchamianie niezawodnych zadań w tle jest niezbędne do budowania aplikacji FastAPI na poziomie produkcji, które obsługują ciężkie lub odroczone prace w niezawodny sposób — i zrozumienie, kiedy i jak używać prawdziwej kolejki zadań, jest ważną wiedzą dla seniorów.

Jądrem decyzji jest rozpoznanie **ograniczeń `BackgroundTasks`** (brak trwałości, ponownych prób czy planowania — dobre tylko dla szybkich, niekrytycznych prac) i sięgnięcie po **Celery lub ARQ**, gdy praca musi być trwała, powtarzalna, zaplanowana, ciężka lub rozproszona (przetwarzanie plików/wideo, wysyłanie hurtowych e-maili, synchronizacja danych, generowanie raportów).

Te kolejki oferują krytyczne możliwości produkcyjne: **trwałość** (zadania przetrwają awarie poprzez brokera, więc praca nie zostanie utracona), **automatyczne ponowne próby** (odporność na przejściowe błędy), **planowanie** (zadania okresowe) i **niezależne skalowanie** pracowników od serwerów internetowych.

Wiedzenie, jak definiować i kolejkować zadania (`.delay()` Celery, natywne API ARQ), architektura (broker + workers), i szczególnie **decyzja, kiedy używać prawdziwej kolejki versus BackgroundTasks**, jest wartościowe dla architektury niezawodnych aplikacji, które odciążają ciężkie prace bez ich utraty — powszechne, ważne wymaganie, które rozróżnia niezawodne systemy produkcyjne od niestabilnych.