Background jobs: сравнение Celery, Huey и APScheduler

Фоновые задачи в Python — это не просто опция, а архитектурная необходимость. От email-рассылок до обработки видео и ML-инференса — background jobs спасают основной поток от блокировки. Но выбор между Celery, Huey и APScheduler — не дело вкуса, а решение с последствиями для задержки, использования памяти и сложности разработки. Погружаемся в глубокий разбор.

Технический разбор: механизмы и внутренности

Celery: Архитектура distributed task queue

Celery — это полноценная распределенная система с брокером (RabbitMQ/Redis), result backend и воркерами. Ключевая особенность — модель ack/nack: воркер подтверждает выполнение только после обработки. Это создает надежность, но увеличивает задержку в сети.

Внутри Celery использует триггеры для ретраев:

countdown: фиксированная задержка
eta: запуск по времени
expires: самоуничтожение задачи

Неочевидный момент: при использовании Redis в качестве брокера, persistence mode напрямую влияет на durability. В rdb режиме вы рискуете потерять задачи при падении Redis. В aof режиме — получите более высокую задержку.

# bind=True дает доступ к self.request для отслеживания прогресса
@app.task(bind=True, max_retries=3)
def process_video(self, video_path):
    try:
        # Обновление состояния — НЕ для прогресса, а для мониторинга
        self.update_state(state='PROGRESS', meta={'current': 0, 'total': 100})

        # Critical: chunk_size влияет на memory usage
        for i in range(0, 101, 10):
            # process_chunk должна быть stateless!
            process_chunk(video_path, i)
            self.update_state(state='PROGRESS', meta={'current': i, 'total': 100})

        return {'status': 'SUCCESS', 'message': 'Video processed'}

    except ConnectionError as exc:
        # Retry с экспоненциальной задержкой — избегает thundering herd
        raise self.retry(exc=exc, countdown=2 ** self.request.retries)
    except Exception:
        # Не ловите Exception без причины!
        raise

Внутренности: Celery использует AMQP протокол для надежной доставки сообщений. Когда задача отправляется, она сериализуется (pickle/json/msgpack) и помещается в очередь. Воркер, используя long-polling, получает задачу. После выполнения результат отправляется в result backend. Проблема возникает при использовании Redis в качестве брокера — он не поддерживает native transactions как RabbitMQ.

Huey: Minimalist with Redis dependency

Huey — это класс Producer-Consumer с Redis как broker/result store. Ключевое отличие: он не поддерживает приоритеты, но умеет планировать задачи через periodic_task.

Внутренняя реализация: Huey использует Redis pub/sub для нотификаций. Когда задача ставится в очередь, она попадает в Redis list. Воркер выполняет блокирующее чтение из этой очереди. Для периодических задач используется Redis sorted sets с timestamp’ами в качестве score.

# Неочевидный момент: RedisHuey не thread-safe по умолчанию!
huey = RedisHuey('my-app', host='localhost', port=6379)

# Task без retries — Huey не поддерживает их из коробки
@huey.task()
def send_email(to, subject, body):
    # Critical: send_email должна быть идемпотентной!
    email_service.send(to, subject, body)
    return f"Email sent to {to}"

# Delayed task — но без ETA, только relative delay
def process_order(order_id):
    result = process_order_data(order_id)
    huey.schedule(
        send_order_notification,
        order_id,
        result,
        delay=timedelta(minutes=5)
    )

Производительность: Huey обрабатывает около 100-200 задач в секунду на одном воркере, в зависимости от сложности. Ограничение — GIL и однопоточная обработка. Для повышения производительности нужно запускать несколько воркеров.

APScheduler: Cron with side effects

APScheduler — это планировщик, а не система очередей. Его триггеры (interval, cron, date) — это просто расписание. Когда приходит время, он вызывает функцию в новом потоке.

Критическая проблема: при запуске нескольких инстансов APScheduler возникает race condition. Без распределенной блокировки (Redis/DB) задачи дублируются. Решение — использовать apscheduler.jobstores.redis или базу данных с блокировками.

# Неочевидный момент: BackgroundScheduler — global object!
scheduler = BackgroundScheduler()

# Job с persistence — но без built-in retries
def import_data(source):
    print(f"Importing from {source}")
    # Critical: функция должна быть stateless!
    process_source_data(source)
    return "Import completed"

# IntervalTrigger — но без jitter, возможны пиковые нагрузки
scheduler.add_job(
    import_data,
    trigger=IntervalTrigger(minutes=30),
    args=['https://api.example.com/data'],
    id='data_import',
    replace_existing=True,
    misfire_grace_time=30,  # Важно!
    coalesce=True  # Объединяет пропущенные запуски
)

# Cron-триггер: час=2, минута=0 — но без timezone-aware
scheduler.add_job(
    generate_daily_report,
    trigger='cron',
    hour=2,
    minute=0
)

# Critical: запуск в отдельном потоке
scheduler.start()

Внутренности: APScheduler использует триггеры для определения времени выполнения. IntervalTrigger проверяет время через фиксированный интервал, CronTrigger вычисляет следующее время на основе cron-выражения, а DateTrigger выполняет задачу в указанное время. Проблема: при запуске в нескольких процессах нет координации.

Узкие места в продакшене: где ломается система

Celery:

Memory leaks: При обработке мелких задач воркеры могут разрастаться до 1GB+ из-за Python GIL. Используйте --max-tasks-per-child для перезапуска воркеров.
Broker failure: При падении RabbitMQ/Redis система полностью останавливается. Настройте high availability для брокера.
Result backend bloating: Бэкенд результатов может разрастаться до десятков гигабайт. Реализуйте TTL для результатов.

Huey:

Redis SPOF: Отказ Redis = полный стоп системы. Настройте Redis Sentinel или Cluster.
No priority support: Критичные задачи могут ждать в очереди за некритичными. Решение: несколько экземпляров Huey с разными очередями.
Limited monitoring: Нет встроенных метрик. Придется городить custom dashboards.

APScheduler:

Duplicate jobs: Без распределенной блокировки в кластере задачи выполняются многократно. Решение: использовать apscheduler.jobstores.redis или базу данных.
No built-in retries: При падении функции задача теряется. Придется реализовывать retry logic вручную.
Resource leakage: Долгие задачи не контролируются scheduler’ом. Придется добавлять timeout и error handling.

Trade-offs: когда выбрать что

Celery:

Когда выбрать: Распределенные системы, высокие нагрузки (>1000 tasks/sec), требуется routing по приоритетам, сложные workflow с зависимостями.
Когда избегать: Небольшие проекты, ограниченные ресурсы инфраструктуры, когда нужна максимальная простота.

Huey:

Когда выбрать: Средние нагрузки, нужен простой планировщик, Redis уже в стеке, когда важна простота развертывания.
Когда избегать: Распределенные воркеры, критичная надежность, когда нужны приоритеты и сложная маршрутизация.

APScheduler:

Когда выбрать: Чисто планированные задачи, локальные инстансы, простые cron-like операции, когда не нужна очередь.
Когда избегать: Распределенные системы, background jobs с retries, задачи с длительным временем выполнения.

Вердикт архитектора

Celery — это как Enterprise Service Bus: мощный, но требует выделенной команды для поддержки. Если ваш проект уже использует RabbitMQ/Redis и вам нужна сложная маршрутизация — ваш выбор. Но для 95% проектов это overkill.

Huey — золотая середина для небольших сервисов. Простота и низкий entry price делают его идеальным для стартапов. Но помните про Redis SPOF.

APScheduler — это не система фоновых задач, а cron со стероидами. Используйте его ТОЛЬКО для запланированных задач, а не для ответов на запросы. Все остальное — верный путь к катастрофе.

Мой личный опыт: Я видел, как проекты с Celery сталкивались с memory leaks при обработке видео чанков. Я видел, как Huey падал при Redis failover. И я видел, как APScheduler дублировал ежедневные отчеты в 5 экземплярах. Нет универсального решения — только архитектурные компромиссы. Тестируйте под ваши нагрузки, а не на демо-данных.

Финальный совет: Начинайте с Huey для простых задач и APScheduler для планирования. Если проект растет и становится распределенным — переходите на Celery. Не выбирайте технологию “на будущее”, а исходите из текущих потребностей.