Как запустить фоновые задачи с помощью Celery?

Question

Accepted Answer

**Celery** — это стандартный инструмент для запуска **фоновых и запланированных задач** в Django — работы, которая не должна блокировать HTTP-запрос (отправка писем, обработка файлов, вызовы медленных API) или работает по расписанию. Задачи ставятся в очередь и обрабатываются асинхронно отдельными процессами **worker**.

## Проблема, которую решает Celery

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

Выполнение медленной работы в линию заставляет пользователей ждать и рискует тайм-аутом запроса. Celery перемещает её на фоновых worker'ов, так что запрос возвращается немедленно.

## Определение и вызов задачи 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
```

Декоратор `@shared_task` определяет задачу; `.delay()` (или `.apply_async()`) ставит её в очередь для обработки worker'ом асинхронно — представление не ждёт.

## Архитектура

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

## Запланированные / периодические задачи (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
    },
}
```

## Функции надёжности

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

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

Обработка фоновых задач с Celery — это важное знание для создания отзывчивых, масштабируемых приложений Django, поскольку многие реальные потребности требуют работы, которая не должна происходить в строке при запросе.

Понимание этого важно, потому что основная проблема — перенос медленной или отложенной работы (отправка писем, обработка изображений/файлов, создание отчётов, вызовы медленных внешних API, синхронизация данных) из цикла request-response — повсеместна в production-приложениях.

Выполнение такой работы в линию заставляет пользователей ждать, рискует тайм-аутом запроса и теряет работу при отказе, тогда как **Celery** позволяет вам ответить пользователю сразу же, пока отдельные **worker'ы** обрабатывают работу асинхронно и надёжно.

Помимо простого асинхронного переноса, Celery предоставляет критические возможности production: **запланированные/периодические задачи** (через Celery Beat, заменяющий cron на уровне приложения — ежедневные отчёты, работы очистки, повторяющиеся синхронизации), **автоматические повторы с backoff** (устойчивость к временным отказам), **сохранение задач** (задачи в очереди выживают при перезагрузке через broker, поэтому работа не теряется), и **независимое масштабирование** worker'ов от веб-серверов.

Понимание архитектуры Celery (broker как Redis/RabbitMQ, содержащий очередь, worker'ы, обрабатывающие задачи, backend результатов), того, как определять и ставить в очередь задачи (`@shared_task`, `.delay()`), планировать периодическую работу и настраивать функции надёжности, — это ценное знание старшего уровня для создания production Django-систем, которые элегантно обрабатывают тяжёлую или отложенную работу.

Поскольку фоновая обработка — это обычное, важное требование для отзывчивых, надёжных приложений, а Celery — это де факто стандартное решение в экосистеме Django, овладение им — это практический, часто релевантный навык, отражающий способность архитектуры реальных Django-приложений за пределами простой синхронной обработки запросов.