Ретраи и устойчивость: бэкофф с джиттером, бюджеты ретраев и circuit breaker

Безопасность ретрая — свойство операции

Прежде чем писать ретрай-цикл, задайте один вопрос: если операция выполнится дважды, результат будет тем же, что от одного выполнения? От ответа зависит, строите ли вы устойчивость или баг двойного списания. Таймаут — не отчёт об отказе, а отсутствие отчёта. Запрос мог умереть на проводе — а мог успеть после того, как вы перестали слушать. Поэтому ретрай безопасен только тогда, когда выполнить операцию дважды — то же самое, что один раз. GET, PUT и DELETE обещают это HTTP-контрактом (если хендлеры его соблюдают); POST не обещает ничего — ретраить затаймаутивший POST /charge, потому что «он упал», и есть способ списать с клиента дважды. Индустриальный фикс — ключ идемпотентности: клиент генерирует уникальный ключ на логическую операцию, шлёт его с каждой попыткой, а сервер хранит результат под этим ключом и на дубликаты переигрывает сохранённый ответ. Exactly-once — ложь, которую сеть не позволяет; ключи идемпотентности реально реализуют at-least-once плюс серверную дедупликацию. Классифицируйте каждое место вызова до написания любого ретрай-цикла: идемпотентно по природе, идемпотентно через ключ или неретраибельно вовсе.

Бэкофф с полным джиттером

Отказы синхронизируют клиентов: рестарт зависимости, сброс кэша, деплой — и тысяча вызывающих падает в одни и те же сто миллисекунд. Если все повторяют попытки по одному расписанию, они возвращаются волной, а голый экспоненциальный бэкофф лишь раздвигает волны: пики на первой секунде, второй, четвёртой — каждый thundering herd по выздоравливающему сервису. Синхронизацию ломает джиттер. Анализ в блоге архитектуры AWS, давший этим стратегиям имена, нашёл полный джиттер — сон равномерно случайное время между нулём и экспоненциальным потолком — близким к оптимуму: клиенты размазываются по окну, стадо превращается в морось, а суммарная работа системы падает драматически по сравнению с бэкоффом без джиттера.

const (
	baseDelay = 100 * time.Millisecond
	maxDelay  = 5 * time.Second
)

// Полный джиттер: равномерно в [0, min(maxDelay, base*2^attempt)).
func backoff(attempt int) time.Duration {
	ceiling := baseDelay << attempt // 100мс, 200мс, 400мс, ...
	if ceiling > maxDelay {
		ceiling = maxDelay
	}
	return rand.N(ceiling) // math/rand/v2: равномерно в [0, ceiling)
}

Бюджеты ретраев: потолок усиления

Джиттер решает проблему синхронизации — но ничего не делает с усилением трафика. Это разные проблемы, и вот механизм, убивший каталожный сервис. При трёх попытках на запрос зависимость со 100% отказов получает втрое больше обычного трафика — ровно когда её ёмкость минимальна. Сложите ретраи по слоям — и они перемножатся: три попытки у клиента и три у гейтвея — до девяти прилётов вниз на одно действие пользователя. Дисциплина из SRE-книги — два потолка. На запрос: максимум три попытки, затем отказ наверх. На клиента: бюджет ретраев — ретраи не превышают примерно 10% запросов в скользящем окне; когда бюджет потрачен, отказы возвращаются немедленно, без ретрая. При тотальном отказе зависимости бюджетированный клиент шлёт максимум 1,1x своей нормы вместо 3x, а ретраи помогают там, где реально помогают, — на транзиентных сбоях, — оставаясь безвредными во время настоящих аварий. И ретраит один слой — тот, что владеет видимым пользователю дедлайном; всё ниже падает быстро наверх.

Таймауты: на попытку, под одним дедлайном

Ретраи и таймауты — одна задача проектирования, и дерево контекстов из первого урока — её скелет. SLO перед вызывающим становится общим дедлайном на ctx; каждая попытка выводит более короткий контекст на попытку, чтобы зависшая попытка умерла быстро, а ретрай мог попасть на более здоровую реплику; и цикл проверяет родителя между попытками, чтобы никогда не проспать дедлайн:

func callWithRetry(ctx context.Context, do func(context.Context) error) error {
	var lastErr error
	for attempt := 0; attempt < 3; attempt++ {
		attemptCtx, cancel := context.WithTimeout(ctx, 500*time.Millisecond)
		lastErr = do(attemptCtx)
		cancel()
		if lastErr == nil || !retryable(lastErr) {
			return lastErr
		}
		select {
		case <-time.After(backoff(attempt)):
		case <-ctx.Done():
			return errors.Join(ctx.Err(), lastErr) // дедлайн сильнее упорства
		}
	}
	return lastErr
}

Пропорции важны: общий дедлайн 2 секунды при попытках по 500 мс оставляет место трём попыткам плюс бэкоффу; дедлайн в секунду при попытках по 900 мс — ретрай-цикл только по названию. Бюджетируйте дедлайн как деньги — попытки, бэкофф и резерв на собственную работу вызывающего.

Circuit breaker: когда тишина сильнее упорства

Бюджет ретраев всё равно отправляет базовую долю трафика в полностью лежащую зависимость — и каждый такой вызов сжигает полный таймаут перед отказом. Circuit breaker (автоматический выключатель) добавляет недостающий конечный автомат. Closed: трафик идёт, отказы считаются в окне. Open: порог отказов сработал; вызовы падают за микросекунды, не трогая сеть, а зависимость получает единственное, что реально помогает ей выздороветь, — тишину. Half-open: после паузы несколько пробных запросов зондируют; успех закрывает брейкер, отказ снова открывает. Брейкер бьёт бюджет, когда зависимость мертва бинарно и когда важна ваша собственная латентность: отказ за микросекунды вместо сжигания 500 мс на обречённый вызов сохраняет ваши горутины, пулы соединений и вызывающих. Честные издержки: состояние на зависимость, два порога и пауза для настройки, ложные срабатывания на малом трафике, где три отказа из пяти запросов — шум, и обязанность явно решить, что является fallback-ом при открытом брейкере.