Как запустить надёжные фоновые задачи (Celery/ARQ)?

Question

Accepted Answer

Для **надёжных, долговечных фоновых задач** (выходящих за рамки облегчённого `BackgroundTasks` FastAPI) используется реальная очередь задач: **Celery** (признанный стандарт) или **ARQ** (современная async-native очередь). Они выполняют тяжёлую, повторяемую, планируемую работу в отдельных рабочих процессах с поддержкой брокера вроде Redis.

## Почему не просто 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 — определение и постановка задач в очередь

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

Эндпоинт ставит задачу в очередь и немедленно отвечает; отдельный процесс **worker** выполняет её с сохранением состояния и повторными попытками.

## ARQ — async-native (соответствует 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 — более лёгкая, async-first альтернатива, привлекательная, когда ваша кодовая база уже async.

## Что предоставляет реальная очередь задач

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

## Почему это важно

Запуск надёжных фоновых задач необходим для разработки production-grade FastAPI-приложений, которые надёжно обрабатывают тяжёлую или отложенную работу — и понимание того, когда и как использовать реальную очередь задач, является важным знанием уровня senior.

Основной выбор — признание **ограничений `BackgroundTasks`** (нет сохранения состояния, повторных попыток или планирования — приемлемо только для быстрой, некритичной работы) и использование **Celery или ARQ**, когда работа должна быть долговечной, повторяемой, планируемой, тяжёлой или распределённой (обработка файлов/видео, отправка массовых писем, синхронизация данных, генерация отчётов).

Эти очереди предоставляют критические production-возможности: **сохранение состояния** (задачи переживают крахи через брокер, так что работа не теряется), **автоматические повторные попытки** (устойчивость к временным сбоям), **планирование** (периодические задачи) и **независимое масштабирование** рабочих процессов от веб-серверов.

Знание того, как определять и ставить задачи в очередь (`.delay()` Celery, async-native API ARQ), архитектура (брокер + рабочие процессы) и особенно **решение о том, когда использовать реальную очередь в сравнении с BackgroundTasks**, ценно для проектирования надёжных приложений, которые выполняют тяжёлую работу без её потери — частое, важное требование, отличающее надёжные production-системы от хрупких.