Работа в полёте: длинные запросы, фоновые джобы и дедлайн

Логика дренажа верна, порядок разбора правильный, страховочный таймаут взведён — и всё это работает прекрасно для запросов, что заканчиваются за пару сотен миллисекунд. Затем ты смотришь, что реально крутится на этом сервисе: CSV-экспорт, что стримит девяносто секунд, воркер транскода видео, что жуёт одну джобу четыре минуты, построитель отчётов на полпути записи строк. Grace period — тридцать секунд. Ни одно из этого не успеет вовремя, и «дай работе в полёте сдренироваться» — правило, что построили прошлые три урока — тихо становится «жди работу, что никогда не закончится до дедлайна, затем всё равно получи SIGKILL посреди записи». Прошлые уроки предполагали, что работа в полёте влезает в окно. Сеньорная реальность — часть не влезает, и притворяться, что влезет, — вот как ты теряешь полузаписанный отчёт и оплату, что была списана, но не записана. Так что вопрос меняет форму: не «как дренировать?», а «что делать с работой, которую дедлайн обрежет?» — и ответ зависит от того, можно ли эту работу безопасно переделать.

Grace period — это бюджет, а не гарантия

Переосмысли grace period как бюджет дедлайна, который ты тратишь, а не отрезок времени, что тебе дан. Всё окно — terminationGracePeriodSeconds, по умолчанию 30s — должно покрыть preStop-сон (распространение, ~5–15s), дренаж keep-alive, разбор ресурсов и запас, что резервирует страховочный таймаут. Что остаётся на собственно дозавершение работы в полёте — это бюджет минус всё это, часто заметно меньше двадцати секунд. Любая единица работы, чьё оставшееся время выполнения превышает этот остаточный бюджет, не закончится, точка. Ошибка — считать grace period «уймой времени» и await’ить всё; сеньорный ход — знать распределение длительности своей работы и принять, что длинный хвост структурно недренируем. Ты можешь поднять grace period для сервиса, где доминируют длинные запросы, но не можешь поднять его без предела — оркестратор, дренаж ноды, дедлайн отзыва spot всё его ограничивают — так что для по-настоящему длинной работы больше времени — не ответ. Ответ — другая диспозиция.

Два рода работы, две диспозиции

Работа, что не влезет, делится на два случая, и они обрабатываются по-разному:

• Длинные синхронные запросы (стриминговый экспорт, медленная загрузка). Ты не можешь вернуть HTTP-запрос в очередь — есть клиент, держащий сокет. Так что выбор: дать ему закончиться, если он близко, или отклонить его чисто, чтобы клиент мог переретраить на здоровый инстанс. Чистое отклонение — это 503 Service Unavailable с заголовком Retry-After, или отказ стартовать новые длинные операции, когда выключение началось. Кардинальный грех — молча оборвать его посреди стрима, что даёт клиенту connection reset, который он не может осмыслить.
• Фоновые джобы (воркер очереди посреди задачи). Здесь у тебя есть реальный вариант, которого нет у HTTP: вернуть в очередь (requeue). Перестань тянуть новые джобы в тот миг, как началось выключение, и для джобы в руках либо закончи её, если влезает, либо отпусти обратно в очередь, чтобы другой воркер подхватил. Большинство очередей делает это за тебя: если воркер умирает без подтверждения (ack), visibility timeout сообщения истекает, и брокер передоставляет его. Эта передоставка — страховочная сетка, но она же и ловушка.

Возврат — at-least-once, поэтому требует идемпотентности

Вот где этот юнит сталкивается с юнитом про идемпотентность, и столкновение — вся суть. Возврат — делаешь ли ты его явно или даёшь visibility timeout сделать — это at-least-once доставка: джоба может выполниться снова с начала. Если воркер был убит после списания карты, но до ack сообщения, передоставленная джоба списывает карту снова. Возврат безопасен, только когда консьюмер идемпотентен — когда выполнение джобы второй раз даёт то же конечное состояние, что и выполнение раз, через ключ идемпотентности, таблицу inbox/dedup или машину состояний, что становится no-op на уже применённой работе. Это не опциональная полировка; это предусловие, что делает возврат корректным, а не генератором двойного списания. Для длинных джоб чекпоинтинг смягчает цену: периодически персисти прогресс, чтобы передоставка возобновилась около места остановки, а не переделывала минуты работы — но чекпоинтинг всё равно полагается на то, что каждый шаг безопасно переприменить. Правило складывается: дренируй то, что влезает, возвращай то, что не влезает, и возвращай только работу, что доказуемо безопасна для выполнения дважды.