cron против time.Ticker и NewTimer

time.Ticker в Go — это канал, в который runtime отправляет значение каждые T с момента создания: равные интервалы от старта, без привязки к часам суток. Канал тикера буферизован на один элемент — второй тик, пришедший к непрочитанному первому, отбрасывается. Это осознанное решение: тикер — механизм уведомлений «пора смотреть», а не очередь заданий. Пара правил сопровождает каждый тикер: останавливать через Stop, когда он больше не нужен, — из урока про утечки горутин видно, что случается с забытыми тикерами, — и читать канал в одном месте, потому что два читателя делят тики между собой. Устройство каналов и select разбирает урок про каналы; здесь важно, что цикл с select по тикеру и отмене контекста — стандартный каркас воркера на равных интервалах.

Тикер отмеряет интервалы от своего старта, и этот факт порождает два следствия. Первое — дрейф: рестарт процесса сдвигает все последующие тики на момент рестарта, и «раз в сутки» оказывается «раз в сутки от запуска». Второе — перекрытие: если работа длится дольше интервала, потребитель не успевает, тики теряются, и фактическая частота падает до скорости обработки. Лечится пара по-разному: перекрытие — флагом занятости или обёрткой с пропуском, а желание «не терять тики» — шаблоном с NewTimer и Reset, где интервал отмеряется от конца работы. Этот шаблон называют равными интервалами с задержкой: работа занимает сколько-то секунд, и следующий отсчёт стартует после неё. Цена та же, что и у дрейфа, — привязка к моменту старта: ни тикер, ни таймер не знают про шесть утра.

cron vs ticker — разница не в удобстве, а в контракте. Планировщик привязывает запуск к календарю: минута, час, день недели, пояс — и переживает рестарты, потому что строка расписания хранится в конфиге, а не в памяти процесса. Тикер привязывает запуск к моменту собственного создания и вместе с ним умирает. Смена расписания без релиза доступна только cron: перезагрузка конфига из урока про изменение расписания меняет частоту и время задач, тогда как интервал тикера зашит в бинарник. Взамен тикер даёт простоту и микросекундные накладные расходы: heartbeat, сбор метрик, батч-выгрузки каждые сто миллисекунд — задачи, где календарная привязка бессмысленна, а строка выражения только мешала бы. Часовые пояса и переводы часов — территория планировщика: механика из урока про пояса работает на строках расписания, тикеру про зоны нечего сказать.

time.NewTimer — третий инструмент: один отсчёт до истечения длительности, значение в канал, конец. Родственная time.AfterFunc вызывает функцию по истечении в отдельной горутине. Типичные задачи таймера — «через N после события»: напоминание о броне за час до начала, повторный опрос через пять минут, отсроченная отправка. Это противоположность планировщика: cron отвечает на вопрос «когда по календарю», таймер — «через сколько от события», и событие чаще всего случается вне расписания. Для накопления напоминаний многих пользователей строится карта таймеров или мини-очередь по срокам — механика разобрана в уроке про напоминания бота. Правила гигиены те же: Stop для отменённого таймера, Reset для переиспользования, осознанность с time.After в горячих циклах — из урока про утечки.

Спорная привычка, которую стоит оспорить: в маленьком сервисе тикер проще, а cron — лишняя зависимость. Аргумент честный: стандартная библиотека не требует go get, а строка расписания — мини-язык, который приходится объяснять коллегам. Но цена тикера в календарных задачах выше, чем выглядит: привязка к моменту старта, потеря расписания при рестарте, отсутствие человеческого формата в конфиге и ручное разруливание перекрытий — это строки кода, которые пишутся поверх тикера и повторяют cron хуже. Верное чтение границы: тикер — выбор по природе задачи, а не по размеру проекта. Равные интервалы без календарной привязки, высокая частота, работа «сразу после старта и с той же частотой» — территория тикера. Привязка к часу, дню недели или поясу, изменение частоты без релиза, задачи, о которых говорит конфиг, — территория cron, и размер сервиса на выбор не влияет.