Почему использовать Celery для выполнения задач вместо cron

Что проверяют

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

Как отвечать

cron умеет одно: запустить процесс в заданное время на конкретной машине. Дальше он ничего не знает: завершилась задача или упала, что делать, если она идёт дольше интервала, как распределить нагрузку, куда девать результат.

Celery это очередь: код кладёт задачу брокеру, воркеры её разбирают. Отсюда то, чего у cron нет:

• постановка из кода, а не только по расписанию: письмо уходит в очередь прямо из обработчика запроса, и пользователь не ждёт отправки;
• повторы: перезапуск с нарастающей задержкой, ограничение числа попыток, отдельная очередь для окончательно упавших;
• распределение: воркеры на нескольких машинах, разные очереди под тяжёлые и быстрые задачи, приоритеты;
• видимость: статус, результат, время выполнения, ограничение частоты запусков;
• расписание тоже есть: периодические задачи ставит beat, так что переносить в Celery можно и то, что уже было в cron.

Честная оговорка: за это платят инфраструктурой, брокер и воркеров надо поднять, мониторить и обновлять. Если задача одна, идёт раз в сутки и её падение не критично, cron проще и надёжнее.

Где спотыкаются

Обещают доставку ровно один раз. По умолчанию она хотя бы один раз: при потере связи с воркером задача уйдёт повторно, поэтому задачи пишут идемпотентными, а не надеются на брокер.

Второе: передают в задачу объект целиком. Аргументы сериализуются, поэтому в очередь кладут идентификатор, а свежие данные воркер читает сам. Иначе он обработает снимок, который уже успели изменить.

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