⏰ Кроны, шедулеры и таймеры: что это и когда применять | Отложенные задачи ⏰

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



📌 Крон (cron)
Это механизм для запуска задач по расписанию в операционных системах.

Примеры:
+ Каждый понедельник очищать временные данные из БД
+ Каждую среду в 03:00 Мск собирать информацию о предстоящих мероприятиях из внешней системы и формировать рассылку для пользователей
+ В банках: формирование ежедневных отчётов по транзакциям в 10:00 и рассылка ответственным
+ В системах аналитики: пересчёт метрик каждые 5 минут.

Технически cron-выражение описывает календарное расписание (минуты, часы, дни, месяцы, дни недели). Некоторые движки cron позволяют указывать секунды, но не во всех реализациях.

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



📌 Шедулер (scheduler)
Это любой механизм, который умеет запускать задачи по расписанию. Более общий термин в отличие от крона.

Шедулер может быть встроенным в приложение или инфраструктурным.

▫️ Cron — это конкретная реализация шедулера на уровне ОС.
▫️ В приложениях шедулеры встроены как часть фреймворков и позволяют описывать расписания внутри системы.

Примеры:

+ в корпоративных системах: Quartz Scheduler (Java) или Hangfire (.NET) запускают задачи внутри приложений

+ в микросервисах: инфраструктурный шедулер Kubernetes CronJob — запускает контейнеры по расписанию

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



📌 Таймер (относительный запуск - delay, timer)
Иногда нужно выполнить задачу не по календарю, а через определённое время после события. Это и есть delay (отложенный запуск) или таймер.

Примеры:
+ Через 15 минут после регистрации отправить напоминание, если пользователь не подтвердил email
+ Повторить запрос через 30 секунд, если система недоступна
+ Отправить уведомление через час после бронирования

Как реализуется:

▫️ Через оперативную память приложения - проще, но ненадёжно, т.к. задача пропадёт при перезапуске.

▫️ Через очередь сообщений - RabbitMQ с плагином для отложенных сообщений, Redis-очереди или др

▫️ Через базу данных - таблица заданий с колонкой execute_at, воркер регулярно проверяет и выполняет



➕ Очереди (queue)
Для задач с большими объёмами «одноразовых» запусков лучше использовать очереди.

Когда выбирать очереди:
▫️ очень много динамических одноразовых задач «через N» (email-напоминания, повторные попытки запросов),
▫️ нужны горизонтальное масштабирование и устойчивость к сбоям,
▫️ гарантии обработки задач важнее точности расписания.

Пример:
Пользователь регистрируется на сайт. Нужно через 30 минут, если он не подтвердил email, отправить ему напоминание.

➡️ При этом регистрируются тысячи пользователей в час.

Решение через очередь с delay:

1. При регистрации создаётся сообщение с инструкцией «отправить напоминание» и параметром задержки delay = 30 минут.

2. Сообщение кладётся в очередь (например, RabbitMQ с плагином Delayed Message Exchange или TTL + DLX).
Важно: RabbitMQ не идеален для очень долгих задержек (дни, недели) — его основная область — секунды/минуты/часы.

3. Через 30 минут брокер отпустит сообщение в потребительскую очередь - т.е. в оперативную обработку.



👉 Правила выбора:

✅ Регулярные задачи по календарю (например, ежедневно в 10:00)
= cron / scheduler

✅ Отложенные одноразовые задачи (выполнить один раз через N времени от текущего момента)
= таймер / delay

✅ Массовые задачи - с большим объемом однотипных действий
= очереди

✅ Подходы могут комбинироваться


Работа с отложенными задачами встречается часто, и термины в разговоре с программистами теперь будут до конца понятны 🤝

#ИнтеграцииGA #АрхитектураGA