Нюансы паттерна Retry

Ещё одна классная статья от Яндекса, на этот раз о особенностях паттерна Retry. Она продолжает тему идемпотентности (если не читали, начните с неё — вот ссылка на пост) и объясняет, как простое решение может создать множество проблем в высоконагруженных системах.

Сам по себе Retry прост как пять копеек: запрос упал — нужно повторить. Но всё становится гораздо интереснее, когда мы начинаем говорить о конфигурации повторов в высоконагруженной системе.

⭐️ Интересные идеи

➡️ Если API идемпотентное, запросы можно безопасно повторять, и внедрение Retry может быть хорошим решением. Однако простые перезапросы могут вызвать так называемый retry storm, который добьёт сервис, которому уже не очень хорошо. В качестве решения стоит использовать exponential backoff — экспоненциальное увеличение времени ожидания между повторными попытками.

➡️ Следующий подвох: если сервису стало плохо, его клиенты могут синхронизироваться даже с учётом exponential backoff и начать слать пачки запросов в одно и то же время. В таком случае используется jitter — дополнительная случайная задержка в паузах между ретраями, которая помогает уменьшить вероятность повторного скопления запросов.

➡️ Если сервис будет в нерабочем состоянии слишком долго, то даже exponential backoff не спасёт. Он лишь отложит нагрузку, но при длительном даунтайме она рано или поздно начнёт расти каскадно и точно добьёт систему. Решение: использовать паттерн Circuit Breaker. В качестве альтернативы можно использовать бюджет на ретраи, но этот подход усложняет логику клиента.

Также в тексте упоминаются ещё несколько интересных паттернов, о которых я напишу позже.

Приятного чтения!

#highload@tech_fit #systemdesign@tech_fit
➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи