Опубликовано: пятница, 19 июня 2026 г.

Даже использование Exponential Retry with...

Автор

Имя
Максим | Системный анализ
Telegram
telegram

Максим | Системный анализ

349 подписчиков

69 постов

Как войти в IT через системный анализ и получить оффер от 270к+. Опыт Senior аналитика из топ-банков. Разборы, практика, собесы, техника мышления аналитика. Бесплатная консультация - в закрепе.

Даже использование Exponential Retry with Jitter не спасает упавший сервис от перегруза, а лишь откладывает большое количество запросов на попозже, надеясь, что к этому времени система восстановится

Но что, если не восстановится? На этот случай у нас припасено три паттерна надёжности: circuit breaker, time limiter и retry budget

Но для того, чтобы понять, как они работают, надо сначала понять ещё один термин

Fallback - это запасная стратегия получения ответа в случае, если сервис недоступен. Чаще всего это получение данных из кеша или частичное отключение функциональности (например, показать корзину без вкладки "рекомендуемые товары")

CIRCUIT BREAKER Это паттерн, который позволяет клиенту не тратить ресурсы на вызов упавшей функциональности. Идея взята из физики. У circuit breaker есть три состояния: Закрыт. Цепь сомкнута, все запросы проходят Открыт. Когда превысили определенный порог ошибок, мы полностью перестаём делать запросы, или используем fallback Полуоткрыт. Когда мы пробыли какое-то время в открытом состоянии, можно попробовать сделать пробный запрос. Если на них пришел ответ, можно переводить circuit breaker назад в закрытое состояние Задача аналитика - понять, когда этот паттерн применим, и при каком пороге клиент должен "открыть" circuit breaker

TIME LIMITER Часто бывает, что клиент не готов ждать дольше определенного времени. В таком случае у него должна быть возможность либо сразу задать тайм-аут, либо направить специальный запрос о том, что он прерывает выполнение и ждёт либо fallback, либо полный откат. Соответственно, аналитику важно продумать полную логику отката RETRY BUDGET Этот паттерн тоже реализуется на стороне клиента, но он в большей степени защищает сам сервер Идея проста: каждый раз клиент считает, сколько он сделал обычных запросов и сколько retry. Когда отношение retry к обычным запросам превышает заданный порог, клиент на время останавливает все retry-запросы. Потом, когда обычных запросов поднакопилось, можно опять пробовать делать ретраи в рамках retry budget

Допустим, наш retry budget это 20%. Наш клиент делает запросы на два эндпойнта одного сервера: информация о пользователе и информация о товарах Пусть на сайт зашли 50 пользователей и у нас появилось 100 запросов. Из них 10 требуют ретрая: 10/100 = 0.1 (10%, это меньше нашего порога в 20%)

Потом произошел сбой на эндпойнте о пользователе, и из следующих 100 запросов целых 50 потребовали ретрая: 60/200 = 0.3 (30%, порог превышен)

В этот момент мы прекращаем все retry-запросы. Если запрос ответил ошибкой, значит все, пользователь сразу увидит ошибку Мы делаем ещё 100 запросов. Если сервис поднялся (и не отработал наш самый первый паттерн, circuit breaker), мы увидим следующие цифры: 60/300 = 0.2 (20%, ровно наш порог) Мы снизили процент до порога нашего retry budget, и можем снова делать ретраи 🎉 А если сбой на одном эндпойнте повел к каскадному отказу всего сервера, то мы хотя бы не будем его добивать кучей ретраев ☝️Соответственно, аналитику в ТЗ, помимо retry policy, важно ещё указать, какие паттерны надежности должен применять клиент

Как вы думаете, как обычно подбираются пороги для этих паттернов? @maximbelovmentor

Обсудить в Telegram

Максим | Системный анализ

349 подписчиков

69 постов