Очередь против крона: что выбрать и почему

Крон подходит, чтобы раз в час запустить резервное копирование, но начинает подводить, когда нужно обработать 100 000 писем, повторить неудачную операцию или распределить работу между несколькими серверами. Очередь решает другую задачу: хранит задания и передаёт их воркерам. Поэтому выбирать нужно не между двумя конкурентами, а между двумя слоями системы — планировщиком и механизмом доставки работы.

Крон и очередь решают разные задачи

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

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

Это важное различие. Крон может быть источником заданий для очереди: раз в пять минут он ставит в очередь задачу «собрать новые заказы», а воркеры разбирают отдельные заказы независимо друг от друга.

Крон определяет момент старта. Очередь определяет судьбу работы после старта.

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

Три рабочих подхода

1. Только cron

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

• Плюсы: почти не требует инфраструктуры, прозрачен для администратора, легко проверить расписание и журналы.
• Минусы: нет встроенного распределения нагрузки, повторов и надёжной истории выполнения. Если команда длится дольше интервала, запуски могут пересекаться.
• Цена решения: вы экономите на брокере и воркерах, но должны сами решить блокировки, тайм-ауты, оповещения и обработку ошибок.

Крон особенно уместен, когда пропуск одного запуска не критичен. Если ночная очистка не сработала, её можно выполнить на следующем цикле. Для отправки платежного уведомления такая терпимость уже опасна.

2. Только очередь

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

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

Очередь не заменяет расписание автоматически. Для задачи «выполнять каждый день в 03:00» понадобится планировщик: встроенный механизм выбранной системы, отдельный сервис или cron, который будет добавлять задания в очередь.

3. Гибрид: cron ставит задачи, очередь их выполняет

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

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

Гибрид требует защиты от повторной постановки. Если cron завершился с ошибкой после добавления части заданий и затем запустился снова, система должна понимать, какие объекты уже запланированы. Обычно для этого используют уникальный идентификатор операции и проверку состояния в базе данных. Конкретный способ зависит от очереди и модели данных.

Сравнение по цене ошибки

Когда выбирать cron

Оставляйте cron, если одновременно выполняются четыре условия:

1. задача запускается по времени, а не по потоку событий;
2. обычно она завершается быстрее интервала между запусками;
3. её можно безопасно повторить целиком;
4. ошибка не приводит к потере денег, данных или обязательного уведомления.

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

Когда очередь оправдана

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

Не добавляйте очередь только потому, что она выглядит современнее cron. Если у вас одна еженочная команда на несколько секунд, брокер и отдельные воркеры увеличат число компонентов, которые нужно обновлять и контролировать.

Что ломается первым

Дубли

Запуск, повтор после тайм-аута и повторная доставка сообщения — разные причины, но результат может быть одинаковым: письмо отправится дважды, платёж проведётся повторно, запись появится два раза. Обработчик должен быть идемпотентным¹ или проверять уникальность операции в базе.

Долгая задача блокирует расписание

Если cron запускает задачу каждые пять минут, а она выполняется десять минут, процессы начнут пересекаться. Защита от этого — блокировка, проверка уже идущего запуска или перенос работы в очередь. Важно не ограничиваться удалением старого lock-файла: после падения сервера можно оставить или снять блокировку в неподходящий момент.

Очередь растёт незаметно

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

Повтор запускает опасную операцию

Автоматический retry полезен для временного сбоя сети, но вреден для необратимой операции без ключа идемпотентности. У повторов должны быть лимит, задержка и отдельный маршрут для задач, которые не удалось выполнить после последней попытки. Такая очередь часто называется dead-letter queue, но точное название зависит от выбранного инструмента.

Как принять решение на проекте

1. Опишите событие. Если работа должна начаться в 02:00, нужен планировщик. Если она возникает после действия пользователя, естественный кандидат — очередь.
2. Посчитайте единицу работы. «Обновить весь каталог» хуже, чем тысячи задач «обновить один товар», если элементы можно обрабатывать независимо.
3. Определите допустимую задержку. Для отчёта допустимы минуты или часы, для подтверждения заказа — секунды. От этого зависит число воркеров и правила повторов.
4. Опишите повтор. Что произойдёт, если процесс завершился после записи в базу, но до подтверждения задания? Если ответа нет, рано включать автоматические повторы.
5. Назначьте показатели. Для cron нужен результат и длительность каждого запуска. Для очереди — длина, возраст старого задания, ошибки и время от постановки до завершения.

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

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

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