Стратегии retry: backoff, jitter и thundering herd

Сервис возвращает 503. Тысяча клиентов планирует retry ровно через 2 секунды. В T+2с тысяча запросов бьёт восстанавливающийся сервер одновременно — тот самый спайк, который сломал его в первый раз. Механизм retry только что усилил outage.

Exponential backoff: базовая формула

Минимально жизнеспособный retry loop ждёт дольше перед каждой следующей попыткой:

delay = min(cap, base × 2^attempt)

base обычно 100–500 мс. cap обычно 30–60 с. Попытки ограничены 3–6 в зависимости от критичности операции.

С base = 200мс и cap = 30с:

• Попытка 1 → ждём 200 мс
• Попытка 2 → ждём 400 мс
• Попытка 3 → ждём 800 мс
• Попытка 4 → ждём 1 600 мс
• …
• Попытка 8 → ждём 30 с (cap)

Проблема: если 1000 клиентов упали одновременно, все выберут одну задержку и ретраят в один и тот же момент — синхронизированный спайк и есть thundering herd.

Jitter: размазываем retry по времени

Три варианта jitter (названы в AWS Architecture Blog):

Full jitter (рекомендован по умолчанию):

delay = random(0, min(cap, base × 2^attempt))

Выбирает случайное значение от 0 до экспоненциального cap. Самое плавное распределение. Проще всего реализовать.

Equal jitter:

delay = (base × 2^attempt)/2 + random(0, (base × 2^attempt)/2)

Половина детерминирована, половина случайна. Сложнее рассуждать.

Decorrelated jitter (используется в AWS SDK v3):

delay = min(cap, random(base, prev_delay × 3))

Окно каждого retry зависит от предыдущей задержки. Растёт органично. Эмпирически похож на full jitter по профилю нагрузки.

Избегай чистого exponential backoff без jitter — это учебниковая thundering-herd ловушка.

Что ретраить — и что нет

Условия retry важны не меньше, чем тайминг:

Ретрай: 5xx-ошибки, network timeout, connection refused, 429 Too Many Requests (с Retry-After).

Не ретрай: 4xx-ошибки (кроме 408 и 429) — запрос клиента некорректен, retry даст тот же 4xx. 410 Gone — ресурс окончательно отсутствует.

Многие библиотеки наивно ретраят всё не-2xx, порождая retry storm на клиентские баги. Явно перечисляй условие retry в конфигурации.

Retry-After: подсказка сервера по backoff

Когда сервер возвращает 429 или 503, он может включить Retry-After: 30 (секунды) или абсолютную дату. Хорошо настроенный клиент уважает это перед применением своего backoff. gRPC использует трейлер grpc-retry-pushback-ms для того же.

Клиент, игнорирующий Retry-After и применяющий короткий собственный backoff — это thundering-herd в действии. Сервер попросил передышку, клиент отказал.

Retry budget: ограничиваем суммарный retry по call site

Индивидуальных ограничений попыток (3–6) недостаточно на масштабе. Retry budget — token-bucket допустимых retry в секунду по всему call site. Когда bucket опустел, клиент открывает circuit и возвращает детерминированную ошибку — перестаёт бить downstream.

Без retry budget outage сервиса заставляет каждого клиента сжечь свои 6 попыток одновременно, умножая трафик в 6 раз и превращая 30-секундный блип в минутный outage.