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

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

Плохо настроенный retry не просто не помогает — он может превратить 30-секундный сбой в 30-минутный outage. Вот почему, и что делать вместо этого.

Минимально жизнеспособный 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 к любому клиентскому вызову, спроси себя: если запрос вернёт 400, поможет ли повтор? Ответ определяет, нужен ли retry вообще.

Условия 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.