Очередь против крона: что выбрать для реальных задач

Ежедневный отчёт можно запустить одной строкой в cron, но обработка 100 000 изображений или повторная доставка вебхука быстро превращают расписание в источник сбоев. Крон отвечает на вопрос «когда стартовать», а очередь — «кто выполнит работу, что делать при ошибке и как пережить пик». Ниже — сравнение на конкретных задачах для Linux cron и Celery 5.x с брокером Redis 7.x или RabbitMQ; точная конфигурация зависит от вашего стека.

Главное различие: расписание и выполнение — не одно и то же

Cron по расписанию запускает процесс или HTTP-запрос. Если команда завершилась с ошибкой, cron сам по себе не хранит задание для повторной попытки, не распределяет работу между воркерами и не знает, что один запуск ещё выполняется.

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

Но очередь не заменяет планировщик автоматически. Для запуска задания каждый час нужен отдельный механизм: системный cron, systemd timer или планировщик вроде Celery beat. На практике часто используется связка: планировщик создаёт задания, очередь распределяет их между воркерами.

Крон хорош, когда важен момент старта. Очередь нужна, когда важны управляемая обработка, повторные попытки и контроль нагрузки.

Идемпотентность¹ — свойство операции, при котором повторный запуск не меняет корректный результат. Например, повторная синхронизация заказа обновляет ту же запись, а не создаёт второй заказ.

Четыре задачи, на которых выбор становится очевидным

Ночной отчёт и очистка временных файлов

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

Очередь здесь добавит брокер, воркер, мониторинг и правила повторов. Это оправдано, если отчёт регулярно блокирует веб-приложение, выполняется в несколько этапов или его нужно запускать для разных клиентов независимо.

Главный риск cron — наложение запусков. Если задача должна завершиться за 10 минут, а расписание запускает её каждые 5 минут, появятся параллельные процессы. Нужна блокировка или проверка активного запуска. Ни cron, ни systemd timer не должны считаться защитой от дублей бизнес-операции.

Обработка изображений после загрузки

Запускать ресайз всех новых файлов раз в минуту через cron можно только при небольшом и предсказуемом потоке. При всплеске загрузок пользователь ждёт следующего запуска, а один долгий процесс начинает конкурировать с веб-сервером за CPU и память.

Очередь лучше подходит для модели «одно изображение — одно задание». Воркеры можно ограничить по числу процессов, не блокируя запрос загрузки. Если обработка упала из-за временной ошибки, повторить можно только конкретное изображение, а не всю пачку.

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

Доставка вебхуков и уведомлений

Для вебхука cron почти всегда даёт неправильную модель. Партнёр может отвечать 30 секунд, временно вернуть ошибку или принять запрос, но не обработать его из-за собственной проблемы. Периодический скрипт не знает надёжно, какой именно вызов нужно повторить.

В очереди каждое событие получает отдельное задание. Для него можно хранить число попыток, задержку между ними и окончательный статус. Отдельная очередь для медленных или ненадёжных получателей не даст им остановить доставку остальных событий.

Здесь особенно важны тайм-аут, ограничение числа повторов и дедупликация. Повторный HTTP-запрос может быть принят партнёром дважды, поэтому отправитель должен передавать стабильный идентификатор события, если принимающая сторона это поддерживает.

Импорт большого файла

Для файла на несколько тысяч строк cron может запускать импорт по расписанию, если пользователь готов ждать результата и процесс можно безопасно продолжить после остановки. Но при больших файлах один скрипт превращается в длинную транзакцию: растёт время блокировок, увеличивается объём памяти, сложнее понять прогресс.

Очередь позволяет разбить файл на порции. Задания обрабатывают диапазоны строк или отдельные сущности, а в базе сохраняются состояние импорта и номер последней успешно обработанной порции. Это ускоряет восстановление, но требует аккуратно определить границы порций и поведение при повторе.

Сравнение подходов по цене и рискам

Как выбирать без архитектурного гадания

1. Сначала определите единицу работы. Если задача — «запустить один скрипт ночью», cron подходит. Если её можно разделить на независимые элементы, очередь обычно даст больше контроля.
2. Проверьте последствия сбоя. Пропущенная очистка временных файлов редко критична. Непоставленное письмо, потерянный платёжный webhook или частичный импорт требуют сохранённого состояния и повторной обработки.
3. Посчитайте пик, а не среднее. Важны количество заданий за короткий период, максимальная длительность одного задания и доступные CPU, память, соединения с базой. Если очередь растёт быстрее, чем воркеры успевают её разбирать, она только скрывает перегрузку.
4. Решите, допустим ли дубль. Если повтор опасен, до выбора инструмента спроектируйте идемпотентность и уникальный ключ операции. Установка Celery или Redis сама по себе от дублей не защищает.

Когда оставлять cron

Оставляйте cron, если процесс короткий, запускается редко, имеет понятный код возврата, а пропуск или повтор можно обнаружить по логу. Для одиночного сервера также стоит рассмотреть systemd timer: он лучше вписывается в управление сервисами systemd и позволяет описывать зависимости и ограничения запуска. Это всё ещё планировщик, а не очередь.

Когда переходить на очередь

Выбирайте очередь, если пользователь не должен ждать завершения работы, задания приходят неравномерно, нужна параллельность или повтор только неудачного элемента. Для Celery 5.x понадобятся отдельные процессы воркеров и брокер сообщений; Redis 7.x проще начать, RabbitMQ обычно выбирают, когда нужны более выраженные возможности маршрутизации и подтверждения сообщений.

Не переносите в очередь задачу только потому, что она «долго работает». Если причина — медленный запрос к базе или отсутствие индекса, очередь скроет проблему, но не устранит её. Сначала измерьте время SQL-запросов, блокировки, загрузку CPU и память процесса.

Что обычно ломается

• Задача выполняется дважды. Воркер мог завершить работу, но не успеть подтвердить сообщение из-за разрыва соединения. Защитите бизнес-операцию уникальным ключом и проверкой уже обработанного события.
• Повторы создают лавину. Если внешний сервис недоступен, мгновенные повторы увеличивают нагрузку. Нужны задержка, ограничение числа попыток и отдельное состояние «требует ручной проверки».
• Очередь растёт бесконечно. Проверьте производительность одного задания, число воркеров, лимиты базы и время ожидания внешних сервисов. Увеличивать воркеры без лимита опасно: база может стать узким местом.
• Cron запускает новую копию. Добавьте механизм блокировки, проверку длительности и метрику пропущенных запусков. Для критичных операций одной записи в текстовом логе недостаточно.

Что измерять перед переключением

Без замеров нельзя честно обещать, что очередь ускорит систему. Зафиксируйте размер входной пачки, длительность одного задания, количество параллельных исполнителей и нагрузку на базу. Затем сравните:

• время от постановки до начала обработки;
• время полного выполнения и долю неудачных попыток;
• максимальную длину очереди и возраст самого старого задания;
• число повторов, дублей и заданий, ушедших в ручную обработку;
• нагрузку CPU, память, количество соединений с базой и внешние тайм-ауты.

Для cron те же показатели нужно собрать из логов и системного мониторинга: время старта, завершения, код выхода и факт наложения запусков. Сравнивайте одинаковый объём данных и одинаковые ограничения по ресурсам, иначе результат будет случайным.

Что делать дальше

Возьмите одну конкретную задачу и опишите её как цепочку: источник события, единица работы, допустимый срок, последствия ошибки и безопасный повтор. Если это одиночный ночной скрипт — начните с cron или systemd timer и добавьте мониторинг кода выхода. Если работа состоит из независимых элементов — протестируйте очередь на ограниченном числе воркеров, отдельно измеряя длину очереди, повторы и нагрузку на базу.

Следующим шагом после запуска будет не добавление новых воркеров, а настройка идемпотентности, тайм-аутов и алерта на старые задания. Документацию по периодическим задачам Celery и таймерам systemd сверяйте с версиями, установленными у вас: названия параметров и поведение интеграций могут меняться.