Celery и фоновые задачи
Тема дорожной карты · Backend разработчик
Celery — распределённая очередь задач для Python, выгружающая времязатратную или отложимую работу — отправку писем, обработку изображений, генерацию отчётов, вызовы сторонних API — из синхронного цикла запрос/ответ Django или FastAPI-бэкенда в фоновые воркеры. Celery требует брокера сообщений для транспортировки задач между производителями и воркерами: Redis и RabbitMQ — два наиболее распространённых варианта, причём Redis предпочтителен за простоту, а RabbitMQ — за расширенную маршрутизацию, dead-letter очереди и долговечное сохранение задач. Задачи определяются как обычные Python-функции, декорированные @shared_task или @app.task, а производители ставят их в очередь через .delay() или .apply_async(), опционально указывая countdown, ETA, маршрутизацию очереди и политики повтора. Планировщик Celery beat расширяет систему до периодических задач — cron-подобные задания, обновляющие кеши, генерирующие ночные отчёты или удаляющие истёкшие записи базы данных, — заменяя crontab для планирования на уровне приложения. В продакшене Celery-воркеры работают как отдельные Docker-контейнеры в Kubernetes рядом с веб-сервисом; конкурентность воркеров, маршруты задач и лимиты повторов управляются через переменные окружения и мониторятся через Flower или метрики Prometheus, экспортируемые celery-exporter.
Как это работает
Celery и фоновые задачи использует кеши (Redis, Memcached, in-process LRU) чтобы избежать дорогого DB или compute, и очереди (Redis Streams, RabbitMQ, Kafka, SQS) чтобы развязать медленную async-работу от request-пути. Стратегии инвалидации кеша: TTL (истечение по времени), write-through (обновлять кеш на запись), event-driven (инвалидация на связанное изменение), cache-aside (читаем кеш, fallback на БД). Паттерны очередей: work queues, pub/sub, exactly-once vs at-least-once.
Когда применять
Кеш — когда замер показывает повтор дорогого compute; никогда "превентивно". TTL-кеш — для данных с допустимой staleness (5-60 секунд закрывает большинство кейсов). Очереди — когда запрос триггерит работу, не помещающуюся в response window (отправка email, обработка файлов, вызовы third-party): возвращайте 202 Accepted + status URL. Consumers очередей — это сервисы со своим мониторингом + репликами.
Типичные ошибки
Ловушки Celery и фоновые задачи: stale-кеш, потому что забыли инвалидировать на связанном пути (знаменитая "две сложные проблемы"); cache stampede, когда ключ протух и N запросов одновременно бьют в БД (stale-while-revalidate или singleflight); at-least-once очереди без идемпотентных consumer (дубль emails/charges); не мониторите lag очереди (тихий backlog растёт, потом взрывается).