Плавная остановка воркеров

Сигнальный обработчик asynq подписан на три сигнала: SIGTERM, SIGINT и SIGTSTP. TERM и INT — путь завершения: сначала вызывается Stop, затем Shutdown, после чего Run возвращает управление, и main завершается. TSTP — путь паузы: только Stop, процесс продолжает жить и держать соединения, о нём отдельно ниже. Stop переводит сервер в состояние stopped: процессор прекращает вытаскивать новые задачи из очередей — очередь копит их до следующего запуска или следующего пода. Активные хендлеры не прерываются: они продолжают работать до своего конца или до истечения лимита дожима, о котором дальше. Логи честно показывают каждый шаг: «Stopping processor» на входе, «Processor stopped» после, затем «Starting graceful shutdown» и «Waiting for all workers to finish...». Обратите внимание, что остановка двухфазная сознательно: сначала очередь замораживается на входе, потом разбирается остаток — так новые задачи не приходят, пока живые воркеры заняты дожимом старых. Практический вывод для локальной отладки: Ctrl+C в терминале — это SIGINT, и он запускает тот же полный цикл, что и деплойный TERM, поэтому остановку воркера можно репетировать без оркестратора — просто следите за логами. Если же процесс не реагирует на сигнал вовсе, проверьте, не запущен ли он через Start без вашего обработчика: в этом режиме asynq сигналы не ловит, и процесс умирает без всякого дожима.

У запуска два режима, и выбор определяет, кто ловит сигналы. Run — самодостаточный: старт, ожидание сигнала, Stop и Shutdown внутри; возвращает ошибку только старта. Он рассчитан на выделенный воркер, где больше ничего нет. Start — фоновый: запускает те же горутины и немедленно возвращает управление. Он нужен, когда в одном процессе живёт ещё и HTTP-API — связка из двадцать первого урока: веб-сервер слушает порт, воркер обрабатывает задачи, и завершать их надо согласованно. С Start обработчик сигналов пишете вы: signal.Notify по SIGTERM, затем srv.Stop() — дожим активных задач, затем srv.Shutdown() и только после него остановка HTTP-сервера. Порядок важен: Shutdown обязан вызываться перед выходом — Stop лишь останавливает забор, и процесс без Shutdown не завершится корректно. Учтите и состояние сервера: уже закрытый сервер вернёт ErrServerClosed из повторных Start и Run — проверяйте errors.Is, если в вашей архитектуре сервер может останавливаться дважды. Для простого воркера Run покрывает всё; Start — инструмент для процессов, где у остановки есть хозяин.

Дожим — сердце плавной остановки. После Stop новые задачи не берутся, но активные хендлеры продолжают работать; Shutdown запускает для них таймер. Длительность задаёт ShutdownTimeout в конфиге сервера: если поле не задано или ноль, работает дефолт — восемь секунд. До истечения таймера всё развивается штатно: хендлер успел и вернул nil — задача закрывается успешной; вернул ошибку — обычный ретрай из шестого урока. Если же попытка не уложилась в ShutdownTimeout, процессор снимает её силой: контекст хендлера отменяется, а задача возвращается в pending — в логах это «Pushed task id back to queue». Никакой потери нет: задача подхватится другим воркером — скорее всего, свежеподнятым подом нового релиза. Но исполнение начнётся с нуля, и всё, что попытка успела сделать до отмены, обязано быть безопасным для повтора — восемнадцатый урок здесь обязательная база. Отсюда же понятна цена больших значений: ShutdownTimeout — верхняя граница времени деплоя, и каждый неуложившийся хендлер тормозит выкатку, сколько бы вас ни просили «подождать, сейчас доделает». Полезно знать и границы: дожим дожидается только тех, кто уже работает. Задачи, которые процессор ещё не успел вытянуть, остаются в очереди нетронутыми — для них остановка не видна. Поэтому прирост pending после деплоя — хороший датчик здоровья лестницы таймаутов: ноль после каждого выката значит, что числа подобраны верно, а постоянный рост — что дожим короче реальных хендлеров.

В k8s и systemd остановка воркеров — рутина каждого деплоя, и она строится по лестнице из трёх чисел. Нижняя ступень — таймаут задачи из одиннадцатого урока: потолок длительности одной попытки, он же обещание «длиннее этого задача не живёт». Средняя — ShutdownTimeout: сколько ваш сервер готов дожидаться активных хендлеров. Верхняя — terminationGracePeriodSeconds в манифесте пода или в юните systemd: сколько оркестратор ждёт после SIGTERM, прежде чем слать SIGKILL. Каждая ступень обязана помещаться в предыдущую с запасом: таймаут задачи больше ShutdownTimeout не имеет смысла — попытка всё равно снимется на дожиме; ShutdownTimeout вплотную к grace period оставляет процессу ноль секунд на собственное завершение — соединения с Redis закроются криво. Приятно, что несколько реплик деплоятся независимо: старый под останавливается и возвращает недоделанное в очередь, новый поднимается и разбирает её — снаружи это выглядит как непрерывная работа. Отдельно упомяну preStop-хуки: они не обязательны, asynq всё делает по сигналу, но полезны, когда перед остановкой надо дать балансировщику исключить под из ротации.

Связка с одиннадцатым уроком здесь не теоретическая: Timeout(10*time.Minute) у задачи превращает дефолтный дожим в фарс — восемь секунд против десяти минут, попытка снимется почти наверняка и вернётся в очередь почти пустой. Варианта три. Первый — дробить длинную работу на шаги и проверять ctx.Done() между ними: хендлер, который между шагами смотрит на контекст, снимается вежливо, на границе атомарных шагов, и идемпотентность из восемнадцатого урока закрывает последствия. Второй — наращивать ShutdownTimeout до самого долгого штатного хендлера и следить, чтобы grace period по-прежнему покрывал его с запасом; цена — медленный деплой, потому что остановка ждёт именно этот хендлер. Третий — принять повторы как данность: короткий дожим, безопасные хендлеры, задача вернётся и доделается. Выбор зависит от цены повтора: для письма сгодится третий, для списания денег — только первый или второй. Что точно не работает — игнорировать вопрос: по умолчанию любой хендлер длиннее восьми секунд деплой будет рвать.