Очередь задач at-least-once

Сделай захват атомарным, чтобы два воркера никогда не брали одну задачу. Наивный паттерн — SELECT ожидающей строки, затем UPDATE в in-flight двумя операторами — это гонка: между SELECT и UPDATE другой воркер может SELECTнуть ту же строку, и оба её UPDATEнут, дважды захватив одну задачу. Почини, схлопнув выборку и блокировку в один оператор: `SELECT ... FOR UPDATE SKIP LOCKED` внутри транзакции, которая также UPDATEит строку в in-flight и RETURNит её. FOR UPDATE блокирует строку, SKIP LOCKED заставляет второго воркера пропустить заблокированную строку вместо блокировки (простой FOR UPDATE сериализовал бы всех воркеров на горячей таблице очереди, добавляя латентность ожидания блокировки пропорционально числу воркеров). Докажи: запусти двух конкурентных воркеров, опрашивающих одну очередь со 100 ожидающими задачами, и убедись, что они никогда не получают один id задачи и что пропущенная строка немедленно доступна другому поллеру — throughput захвата масштабируется с числом воркеров, а не с ожиданиями блокировок.

Добавь visibility timeout, чтобы задача, чей воркер умер до ack, не терялась — становилась снова доступной для захвата по истечении таймаута вместо вечного зависания в 'claimed'. Таймаут — самая чувствительная ручка настройки очереди, и сеньорная ошибка — ставить его интуитивно: слишком короткий — медленный, но живой воркер гонится за собственной задачей (задача перепоставлена и обрабатывается дважды параллельно, риск дублирующихся эффектов); слишком длинный — реальный краш стопорит полосу на минуты, прежде чем другой воркер сможет её подобрать. Правильное значение чуть выше p99 длительности задачи, не p50 и не консервативный 10x. Реализуй: захваченные задачи несут `visible_at = now + visibility_timeout`; sweep-процесс или предикат захвата `WHERE visible_at < now()` перепоставляет просроченные задачи. Докажи краш-тестом: убей воркера на середине задачи (SIGKILL до ack) и покажи, что задача становится доступной ровно по истечении visibility timeout, не потеряна и не немедленно.

Позволь длинным задачам переживать visibility timeout, не будучи украденными. Задача, чья реальная длительность превышает таймаут, иначе была бы перепоставлена, пока ещё выполняется — два воркера тогда обрабатывали бы одну задачу параллельно, превращая at-least-once в at-least-twice с перекрывающимися эффектами. Фикс — heartbeat, продлевающий аренду: воркер периодически UPDATEит `visible_at = now + visibility_timeout` на подинтервале таймаута (например, каждую timeout/3), пока задача in-flight. Продление должно быть атомарным и не продлевать задачу, уже перепоставленную (проверь `WHERE status='claimed' AND visible_at` всё ещё совпадает). Докажи: запусти задачу, спящую 3× visibility timeout с heartbeat, и покажи, что она никогда не перепоставлена; убей heartbeat на середине и покажи перепостановку через один таймаут. Задокументируй, почему увеличение самого таймаута (вместо heartbeat) неверно — оно бы стопорило реальные краши на всю длинную длительность.

Сделай консьюмер идемпотентным, чтобы повторно доставленная задача — будь то из visibility timeout или потери heartbeat — давала ровно один эффект. Единственный честный способ — записать ключ идемпотентности в той же транзакции, что и бизнес-эффект: `INSERT dedup_key` + `UPDATE business_table` в одном коммите. Если они в разных коммитах, краш между ними либо применяет дважды (эффект закоммичен, ключ дедупа нет — следующая доставка применяет снова), либо повторяет вечно (ключ дедупа закоммичен, эффекта нет — следующая доставка ошибочно считается выполненной). Натуральный ключ идемпотентности задачи (например, `job_id` или `order_id`) хранится в таблице дедупа с unique-ограничением; повторная доставка с тем же ключом попадает в ограничение и становится no-op. Докажи: обработай одну задачу дважды с тем же ключом и убедись в ровно одном бизнес-эффекте; сымитируй краш между эффектом и вставкой дедупа (провалив транзакцию) и покажи, что ничто не видимо.

Добавь прод-сетку безопасности: ядовитая задача, всегда падающая, не должна крутиться вечно и занимать голову очереди, блокируя каждую последующую задачу. После N неудач (например, 5) с экспоненциальным backoff и jitter (`delay = base * 2^attempt + rand(0, jitter)`) задача уходит в dead-letter таблицу вместо перепостановки — рост глубины DLQ — самый ранний сигнал, что что-то выше по цепи сломано или payload битый, и алертить надо на него, а не только на латентность. Сделай очередь наблюдаемой: снимай метрики throughput захвата, rate перепостановок visibility, глубину DLQ и p50/p99 длительности задач. Затем прогони хаос-тест: убивай воркеров в каждой точке краша (до захвата, во время задачи, до ack, во время вставки дедупа) под конкурентной нагрузкой и убедись в ноле потерянных задач и ноле небезопасных дублей. Хаос-тест — доказательство, что границы атомарности из этапов 1 и 4 действительно держатся, когда процесс умирает в худший момент.