Отложенные задачи: ProcessIn и ProcessAt

Asynq ProcessIn — опция постановки: client.Enqueue(task, asynq.ProcessIn(1time.Hour)) кладёт задачу не в очередь ожидания, а в расписание. Всё остальное вы уже знаете из уроков про первую задачу: NewTask с типом и payload, Enqueue возвращает TaskInfo, хендлер регистрируется в mux как обычно — меняется только момент исполнения. Поле info.NextProcessAt показывает расчётное время запуска: удобно логировать при постановке, чтобы потом сверить с фактом. Задача при этом переходит в состояние scheduled и живёт в расписании Redis; в дашборде её видно среди отложенных. Задержка принимается любым duration — от секунды до недель, но границы разумного стоит держать в голове: напоминание через минуту лучше ставить как immediate, а расписание на месяцы — повод посмотреть в сторону периодических задач. Механизм одинаков для любых типов: это не отдельный API, а обещание при постановке. Одна деталь, о которой стоит договориться сразу: ProcessIn задаёт нижнюю границу, а не точный момент. Когда срок истёк, задача переходит из scheduled в pending — но исполняется она тогда, когда её заберёт живой воркер с свободным слотом. На здоровом сервисе задержка сверх назначенного времени измеряется секундами; на сервисе с остановленными воркерами — до их возвращения, и это фича, а не баг: задача не потеряна. Отсюда правильные ожидания: напоминания, дедлайны и отложенные письма прощают секунды опоздания, а вот торговые заявки с точностью до миллисекунды — не для очереди с опросом расписания. Отсчёт начинается в момент постановки, а не в момент создания payload: лаг между ними сдвинет задачу целиком. Практика, которая делает код читаемым: держите duration-константы рядом с типами задач — asynq.ProcessIn(24time.Hour) говорит сам за себя, без магических чисел. И постановка с ProcessIn до старта воркеров абсолютно легальна: задача дождётся в расписании, потому что Redis живёт своей жизнью.

ProcessAt принимает time.Time вместо длительности: ProcessAt(when) — «запусти не раньше этого момента». Математически ProcessIn(d) эквивалентен ProcessAt(time.Now().Add(d)), и выбирать стоит по смыслу задачи: длительность — для «через час после события», момент времени — для «в полночь», «в 09:00 по будням», «когда заканчивается триал». Ночной отчёт строится на time.Date: собираем год, месяц и день плюс один, часы-минуты-секунды нулевые — и получаем первую полночь после текущего момента. Таймзона здесь главный источник ошибок: time.Now() живёт в таймзоне сервера, которая в контейнерах почти всегда UTC, и «полночь» без указания места окажется полуднем по Москве. Лечение — time.LoadLocation и явный .In(loc) для всех расчётов времени. Приятный бонус: time.Date нормализует переполнения — день 32 декабря честно превратится в 1 января, и код конца года не потребует особых случаев. Ещё две привычки: держите LoadLocation в инициализации — чтение зоны с диска не бесплатное, и в горячем пути оно вам не нужно; и покройте расчёт тестом с фиксированным now, иначе таймзонные ошибки проявятся только на проде в неправильный час. Напоминание про контейнеры: минимальные образы без tzdata вернут ошибку из LoadLocation — лечится пакетом tzdata в образе или импортом time/tzdata.

Отложенные задачи redis хранит не в списках, как immediate, а в сортированном множестве: член — сериализованная задача, балл — время запуска. Отсюда дешёвые операции расписания: постановка записывает член с баллом, а воркер опрашивает расписание и переводит созревшие задачи в pending-очередь, откуда их забирают хендлеры. Опрос идёт постоянно с коротким интервалом — порядка нескольких секунд, поэтому точность срабатывания в спокойной системе измеряется секундами, а не миллисекундами. Устройство переживает всё, что переживает Redis: рестарты воркеров, рестарты клиентов, перезапуск контейнера — расписание остаётся в хранилище, а не в памяти процессов. Имена ключей менялись между версиями asynq, но принцип один: несколько zset-ов с баллами-временами для scheduled, retry и архива. Если вы прошли курс по go-redis, вы уже встречали сортированные множества с баллами-временами — asynq использует ровно этот приём. Тот же приём обслуживает и повторные: retry-задачи лежат в таком же множестве с баллом-временем следующей попытки, так что ретрай после сбоя и отложенная постановка — близнецы внутри библиотеки. Практический вывод: включённая персистентность Redis — обязательное условие для расписаний, на которые кто-то надеется.

Соберём сценарий из первого блока урока целиком. При создании записи сервис ставит задачу reminder:send с ProcessIn(1*time.Hour) и payload из ID пользователя и текста. В час X воркер выполняет хендлер: достаём пользователя, шлём сообщение, return nil. Всё работает до первого отмененного приёма: напоминание-то уже в расписании, и в час X придёт сообщение о приёме, которого нет. Asynq не умеет «удалить задачу по бизнес-ключу» из клиента — постановка однонаправленна. Два рабочих решения: проверка актуальности в хендлере — смотрим в базу, если приёма нет, return nil молча; или управление задачей через Inspector, который умеет отменять по ID — ему посвящён пятнадцатый урок. Первый вариант дешевле и надёжнее: хендлер-проверка срабатывает и после сбоев, и после ручных правок в базе, тогда как отмена Inspector-ом требует хранить ID каждой поставленной задачи. Проверку в хендлере пишите как обычный guard: достали приём по идентификатору, не нашли или приём отменён — логируете пропуск и возвращаете nil. Ошибка тут была бы вредной: несуществующий приём — нормальный исход, а не сбой, и повтор задачи его не исправит.

Отложенные задачи и cron решают разные вопросы: ProcessIn и ProcessAt отвечают на «когда наступит момент, связанный с событием», cron — на «когда наступит очередной час по календарю». Напоминание о записи привязано к событию, случившемуся сейчас, и живёт в asynq: постановка из кода, payload с данными, ретраи при сбое. Ночной пересчёт рейтингов привязан к календарю и повторяется всегда — это территория cron или периодических задач asynq, которые построены на cron-выражениях и разобраны в девятом уроке. Взрослые схемы используют обе половины: cron ставит периодические задачи, а те, в свою очередь, ставят отложенные — «пересчитать в полночь, а отчёт отправить в девять утра». Если расписание у вас уже живёт в классическом cron, как описано в курсе по cron, asynq спокойно соседствует с ним: процесс-планировщик ставит задачи через client.Enqueue, и отдельного моста не нужно. Гибридный сценарий, где обе половины встречаются в одном предложении: «напомнить за сутки до дедлайна заказа». Дедлайн — дата из базы, значит, это ProcessAt с рассчитанным моментом, а не cron; зато ежедневный пересчёт дедлайнов — уже календарь. Правильный вопрос к себе всегда один: привязано время к событию или к календарю.