Перейти к содержимому
Опубликовано

Одно из первых полей в шаблоне ТЗ для gRPC -...

Автор
  • Имя
    Максим | Системный анализ
    Telegram

Кратко

Одно из первых полей в шаблоне ТЗ для gRPC - это политика ретраевRetry policy - это набор правил, определяющих, как система повторяет неудавшиеся...

Одно из первых полей в шаблоне ТЗ для gRPC - это политика ретраев

Retry policy - это набор правил, определяющих, как система повторяет неудавшиеся операции (сетевые запросы, обращения к базе данных, микросервисам и т.д.) Какие существуют retry policy:
No Retry (без повторных попыток) Операция выполняется ровно один раз. При ошибке сразу возвращается отказ. самая простая логика, не создаёт дополнительной нагрузки любая кратковременная неполадка становится фатальной Immediate Retry (немедленный повтор) После ошибки запрос повторяется мгновенно, без задержки. Обычно задаётся максимальное количество попыток (например, 2–3). быстрое восстановление при случайных ошибках при устойчивых сбоях создаёт очень сильную нагрузку Fixed Delay (фиксированная задержка) Между попытками выдерживается постоянный интервал (например, 1 секунда). В параметрах указывается количество попыток и интервал ожидания. простая реализация, понятное поведение при совпадении интервалов у многих клиентов могут возникать синхронные волны запросов в один момент (так называемый "шторм ретраев") Linear Backoff (линейная задержка) Интервал увеличивается линейно: 1с, 2с, 3с, 4с и т.д. Задаётся начальная задержка, шаг приращения и максимальное количество попыток. постепенно снижает нагрузку на восстанавливающийся сервис слабее разгружает систему, чем экспоненциальная задержка. Не убирает проблему "шторма ретраев" Exponential Backoff (экспоненциальная задержка) Задержка растёт экспоненциально: 1с, 2с, 4с, 8с, 16с… Чаще всего используется множитель 2 и задаётся максимальная задержка. эффективно снижает нагрузку, даёт сервису время на восстановление, де-факто стандарт в распределённых системах при идентичных начальных параметрах все клиенты могут синхронизироваться, как в предыдущих двух вариантах Exponential Backoff with Jitter (экспоненциальная задержка с джиттером) К экспоненциальной задержке добавляется рандомное слагаемое (jitter). убирает синхронизацию клиентов, предотвращает пики нагрузки слегка сложнее в реализации

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

@maximbelovmentor

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