На прошлых занятиях мы говорили о том, как Circuit Breaker помогает справляться с отказами в микросервисных системах. Мы узнали, как этот паттерн защищает нашу систему от каскадных сбоев и обеспечивает стабильность. Сегодня мы познакомимся с ещё двумя важными инструментами из арсенала разработчика микросервисов — механизмами повторных запросов (Retry) и ограничения времени ожидания (Timeout).
Почему нам нужны Retry и Timeout?
Представьте, что вы пытаетесь дозвониться другу. Телефон занят — вы перезваниваете через минуту. Снова занят — ещё через пару минут. Но вы же не будете названивать бесконечно, верно? В какой-то момент решите: "Ладно, попробую позже".
Вот так же работают и наши микросервисы. Retry (повторные попытки) и Timeout (ограничение времени ожидания) — это как раз те механизмы, которые помогают сервисам решить: когда стоит повторить попытку, а когда лучше сдаться и попробовать позже.
Что такое Retry?
Retry — это механизм повторного выполнения операции в случае её неудачи. Причём не просто повторения как попало, а по определённой стратегии. Например:
- Первая попытка не удалась? Подождём секунду и попробуем снова
- Опять неудача? Ладно, подождём две секунды
- И снова не вышло? Может, четыре секунды?
- Ну а если и это не помогло — тогда уже сдаёмся
Это называется экспоненциальной задержкой (exponential backoff), и это гораздо умнее, чем долбить в закрытую дверь без перерыва.
А что такое Timeout?
Timeout — это как таймер на приготовление пиццы. Если через 30 минут пицца не готова, вы же не будете ждать вечно? Так и в микросервисах: мы устанавливаем максимальное время ожидания ответа. Если сервис не уложился — прерываем операцию.
Почему это важно? Потому что ресурсы системы не бесконечны. Каждый "зависший" запрос — это как занятый столик в ресторане, за которым никто не ест. Чем больше таких столиков, тем меньше мест для реальных посетителей.
Когда использовать Retry?
Retry особенно полезен в следующих ситуациях:
1. Временные сетевые проблемы Представьте, что вы отправляете важное письмо по электронной почте, а интернет вдруг моргнул. Что делает ваш почтовый клиент? Правильно, пробует отправить снова. Точно так же должны работать и микросервисы.
2. Краткосрочные перегрузки сервисов Бывает, что сервис на секунду перегружен — как касса в супермаркете в час пик. Подождать немного и повторить запрос часто бывает эффективнее, чем сразу сдаваться.
3. Проблемы с базой данных Временные блокировки или deadlock в базе данных — частая причина сбоев. Повторный запрос через некоторое время может пройти успешно.
Приведём пример. Давайте представим платёжную систему. Клиент пытается оплатить заказ, но банковский сервис временно перегружен. Что лучше:
- Сразу показать ошибку "Платёж не прошёл, попробуйте позже"?
- Или автоматически повторить попытку через пару секунд?
Конечно, второй вариант! Клиент даже не заметит, что была проблема, если повторная попытка окажется успешной.
Когда нужен Timeout?
Timeout критически важен в следующих случаях:
1. Защита от "зависших" запросов Как в реальной жизни мы не готовы вечно ждать ответа на вопрос, так и в микросервисах нужно устанавливать разумные ограничения времени ожидания.
2. Освобождение ресурсов Каждый долгий запрос — это занятые ресурсы сервера. Timeout помогает их освободить, если операция затянулась.
3. Улучшение пользовательского опыта Лучше быстро получить сообщение "Попробуйте позже", чем смотреть на крутящееся колесико загрузки минуту или две.
Реальный пример: возьмём сервис доставки еды. Когда пользователь ищет рестораны поблизости, сколько времени он готов ждать результатов? Две секунды? Пять? Точно не минуту! Поэтому мы устанавливаем timeout в 3 секунды. Если за это время список ресторанов не получен — показываем пользователю базовый список популярных заведений.
Как они работают вместе?
Retry и Timeout — как хороший тандем полицейских: один пытается достучаться (Retry), другой следит за временем (Timeout).
Например:
- Делаем запрос к сервису
- Timeout следит, чтобы каждая попытка не превышала 5 секунд
- Если получаем ошибку или timeout, Retry решает:
- Подождать и попробовать снова?
- Или уже достаточно попыток?
Важные моменты при совместном использовании
- Настройка времени Timeout для одной попытки должен быть меньше, чем интервал между повторами. Иначе можно получить странную ситуацию, когда новая попытка начинается, пока предыдущая ещё не завершилась.
- Количество попыток Не стоит делать слишком много повторов. Обычно 3-5 попыток достаточно. Иначе можно создать дополнительную нагрузку на и так проблемный сервис.
Подготовка к следующей лекции
На следующем занятии мы возьмём всё это и реализуем на практике с помощью Spring Boot и Resilience4j. Мы напишем реальный код, настроим параметры и увидим, как эти механизмы работают в действии.
А пока подумайте:
- В каких ситуациях в ваших проектах пригодились бы Retry и Timeout?
- Какие параметры Retry вы бы выбрали для разных типов операций?
- Как бы вы определили оптимальное время для Timeout?
До встречи на практике! И помните: временные сбои — это нормально, главное — уметь с ними правильно работать!
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ