Как мгновенно повлиять на ретраи при отсутствии ограничений, вызывающих дидос стороннего сервиса
Что проверяют
Ключевое слово здесь «мгновенно». Интервьюер хочет услышать, как остановить лавину повторов прямо сейчас, без релиза, и только потом, как починить саму стратегию ретраев. Следом обычно спрашивают, почему ретраи вообще превратились в атаку.
Как отвечать
Разделите ответ на срочные меры и системное исправление.
Срочно, без пересборки:
- выключатель: фича-флаг или динамический конфиг, который отключает вызовы или ретраи. Если конфиг лежит в Spring Cloud Config или Consul, бины с
@RefreshScopeперечитают значения без рестарта; - circuit breaker: в Resilience4j автомат переводится вручную методом
transitionToForcedOpenState(), например через служебный эндпоинт, и вызовы сразу отбиваются без обращения к сервису; - ограничение на выходе: rate limit на egress-прокси или в сервис-меше, если он есть;
- меньше источников нагрузки: уменьшить число реплик или поставить на паузу потребителей очереди, которые порождают вызовы.
Системно:
- экспоненциальная задержка с jitter: без случайной добавки клиенты повторяют синхронно и бьют волнами;
- лимит попыток и бюджет ретраев: например, повторы не больше 10% от общего потока запросов;
- что ретраить: таймауты,
503,429, причём на429и503уважать заголовокRetry-After. Прочие4xxне повторять, неидемпотентныйPOSTповторять только с ключом идемпотентности; - один слой ретраев: три попытки на клиенте, три в сервисе и три на шлюзе дают 27 запросов на одно действие пользователя.
В Java для этого берут Resilience4j (Retry, CircuitBreaker, RateLimiter, Bulkhead) или Spring Retry. Hystrix давно в режиме поддержки, называть его современным выбором не стоит.
Где спотыкаются
Отвечают только про backoff. Мера правильная, но она требует релиза, а вопрос был про «прямо сейчас».
Не замечают умножения ретраев по слоям. Каждый слой настроен разумно, а в сумме выходит шквал.
Ретраят всё подряд, включая 400 и POST без идемпотентности. В лучшем случае это лишняя нагрузка, в худшем двойные списания.