Retry Policy в мобильной разработке — суть, стратегии и принцип

Что такое Retry Policy?

Retry Policy — это программная стратегия, определяющая поведение клиента при сбое сетевого запроса: какие ошибки стоит повторять, сколько раз, с какой задержкой и когда прекратить попытки. В мобильных приложениях политика повторов критически важна из-за нестабильности мобильных сетей и возможных временных сбоев на стороне сервера.

Базовая Retry Policy включает три параметра: максимальное количество повторов (maxRetries), начальная задержка (baseDelay) и стратегия увеличения задержки (backoff strategy). Дополнительно может быть задан список HTTP-статусов, на которые следует реагировать повтором, и таймаут для прерывания всех попыток.

По данным книги "Designing Data-Intensive Applications" Мартина Клеппмана, 50% сбоев в распределённых системах являются временными и устраняются при повторной попытке. Это делает Retry Policy одним из самых эффективных и дешёвых способов повышения отказоустойчивости мобильного приложения без изменений серверной архитектуры.

Какие ошибки стоит повторять

Временные ошибки (retriable) — единственный тип сбоев, на которые Retry Policy должна реагировать. К ним относятся таймауты соединения (SocketTimeoutException), временная недоступность сервера (HTTP 503, 502) и ошибки DNS. Постоянные ошибки — HTTP 400, 401, 403, 404 — повторять бессмысленно, так как они указывают на проблему в запросе, а не в сети или сервере.

По данным исследования AWS Architecture Blog, правильная классификация ошибок на retriable и non-retriable — самое важное решение при проектировании Retry Policy. Повтор неидемпотентного запроса на HTTP 401 может привести к блокировке аккаунта, а повтор HTTP 400 — к созданию дубликатов данных. Всегда конфигурируйте список кодов для повтора явно.

Основные стратегии повторов

Fixed interval — самая простая стратегия: каждый повтор выполняется через одинаковый промежуток времени. Например, при задержке 2 секунды приложение повторяет запрос через 2, 2, 2 секунды. Fixed interval прост в реализации и предсказуем, но создаёт равномерную нагрузку на сервер при массовых сбоях.

Incremental interval — задержка увеличивается линейно с каждым повтором: первый повтор через 1 секунду, второй — через 2, третий — через 3 и так далее. Эта стратегия даёт серверу больше времени на восстановление при повторных сбоях, но всё ещё предсказуема для множества одновременно падающих клиентов.

Выбор стратегии зависит от характера приложения. Для фоновых задач синхронизации данных на мобильных устройствах оптимальна exponential стратегия с jitter — она даёт наибольшую вероятность успеха при минимальной нагрузке на сервер и устройство пользователя.

Exponential Backoff и Jitter

Exponential backoff — стратегия, при которой задержка между повторами удваивается с каждой попыткой. Если начальная задержка составляет 1 секунду, то последовательность задержек будет 1, 2, 4, 8, 16 секунд. Это даёт серверу экспоненциально растущее время на восстановление.

Jitter — случайное отклонение задержки, которое предотвращает синхронные повторные запросы от множества клиентов (thundering herd problem). Без jitter тысяча клиентов с одинаковой Retry Policy будет повторять запросы одновременно, создавая пиковую нагрузку на сервер. Jitter разносит повторы во времени.

Реализация на Kotlin с корутинами

Корутины Kotlin позволяют реализовать exponential backoff с jitter без блокировки основного потока. Функция retry из kotlinx-coroutines принимает условие повтора и блок с телом запроса, автоматически управляя задержками и количеством попыток.

suspend fun RetryPolicy.executeWithRetry(
    block: suspend () -> Result<T>
): Result<T> {
    var lastError: Throwable? = null
    repeat(maxRetries + 1) { attempt ->
        try {
            return block()
        } catch (e: Exception) {
            if (!isRetriable(e) || attempt == maxRetries) {
                return Result.failure(e)
            }
            val delay = (baseDelayMs * (1 shl attempt))
                .toLong()
            val jitteredDelay = (delay * (0.5 + Random.nextDouble())).toLong()
            delay(jitteredDelay)
            lastError = e
        }
    }
    return Result.failure(lastError!!)
}

Функция executeWithRetry принимает лямбду с сетевым вызовом и выполняет её с exponential backoff и jitter. Если ошибка не подлежит повтору (не retriable) или превышено максимальное число попыток, функция возвращает ошибку. Задержка домножается на случайный коэффициент от 0.5 до 1.5 для равномерного распределения повторов.

Circuit Breaker и отказ от повторов

Circuit Breaker — паттерн проектирования, который предотвращает бесконечные повторные запросы при длительной недоступности сервиса. Когда количество ошибок превышает порог, Circuit Breaker переходит в состояние OPEN и немедленно возвращает ошибку без выполнения запроса, давая серверу время на восстановление.

В мобильных приложениях Circuit Breaker особенно полезен при недоступности API из-за планового обслуживания или сетевых сбоев оператора. Без него приложение будет потреблять батарею и трафик на бесконечные повторные попытки, ухудшая пользовательский опыт и сокращая время автономной работы устройства.

Схема состояний Circuit Breaker

Три состояния Circuit Breaker: CLOSED (нормальная работа, запросы выполняются), OPEN (отказ, запросы блокируются) и HALF_OPEN (пробный запрос для проверки восстановления). После заданного таймаута в состоянии OPEN переключатель переходит в HALF_OPEN и выполняет один запрос — при успехе возвращается в CLOSED, при неудаче — в OPEN.

class CircuitBreaker(
    private val failureThreshold: Int = 3,
    private val timeoutMs: Long = 30000
) {
    private var state = State.CLOSED
    private var failureCount = 0
    private var lastFailureTime: Long = 0

    suspend fun T.protect(block: suspend () -> T): T {
        checkState()
        return try {
            val result = block()
            onSuccess()
            result
        } catch (e: Exception) {
            onFailure()
            throw e
        }
    }
}

Реализация Circuit Breaker на Kotlin содержит счётчик ошибок и таймер восстановления. Метод protect проверяет текущее состояние перед выполнением блокируемого запроса и обновляет счётчик ошибок при сбоях. После достижения порога failureThreshold все запросы немедленно отклоняются до истечения timeoutMs.

Retry Policy в мобильных приложениях

Мобильные сети имеют особенности, которые делают Retry Policy особенно важной. Переключение между Wi-Fi и мобильными данными, потеря сигнала в метро и тоннелях, временные блокировки на уровне оператора — все эти сценарии приводят к сбоям запросов, которые успешно обрабатываются повторными попытками.

На Android библиотека Retrofit и OkHttp предоставляют встроенный механизм RetryPolicy через Interceptor. На iOS задача решается через URLSessionConfiguration и кастомное делегирование. Для кросс-платформенной разработки Ktor (KMP) содержит встроенную поддержку retry с настраиваемыми стратегиями.

Реализация на iOS с Combine

Combine — фреймворк Apple для реактивного программирования. Оператор retry в Combine повторяет паблишер указанное количество раз при ошибке, но не позволяет настраивать задержку между повторами. Для полноценной Retry Policy используется кастомная комбинация catch и flatMap с задержкой.

extension Publisher {
    func retryWithBackoff(
        retries: Int = 3,
        baseDelay: TimeInterval = 1.0
    ) -> AnyPublisher<Output, Failure> {
        return self.catch { error -> AnyPublisher in
            guard retries > 0 else {
                return Fail(error).eraseToAnyPublisher()
            }
            return Just(())
                .delay(for: .seconds(baseDelay), scheduler: DispatchQueue.main)
                .flatMap { self.retryWithBackoff(
                    retries: retries - 1,
                    baseDelay: baseDelay * 2
                ) }
                .eraseToAnyPublisher()
        }
        .eraseToAnyPublisher()
    }
}

Расширение retryWithBackoff для Publisher в Combine реализует exponential backoff через рекурсивный вызов с уменьшением счётчика и удвоением задержки. Оператор delay создаёт паузу между повторами, а catch перехватывает ошибку и решает, пытаться ли снова или вернуть failure.

Типовые ошибки при Retry Policy

Первая ошибка — повторять запросы без проверки идемпотентности. Если сервер создал ресурс, но не вернул подтверждение из-за сбоя сети, повторный запрос создаст дубликат. Для POST-запросов всегда используйте идемпотентный ключ (Idempotency-Key) в заголовке или переходите на retry только для GET, PUT и DELETE.

Вторая ошибка — бесконечные повторы (retry forever). Всегда устанавливайте максимальное количество попыток (3-5 для мобильных приложений) и общий таймаут на все попытки. Бесконечные повторы разряжают батарею и создают паразитную нагрузку на сервер, особенно при миграции баз данных или изменении API.

Третья ошибка — игнорировать контекст приложения. Если пользователь закрыл приложение или перешёл в фоновый режим, активные Retry Policy должны корректно отменяться. Используйте корутины с SupervisorScope или Combine с жизненным циклом UI для автоматической отмены повторов при закрытии экрана.

Четвёртая ошибка — не логировать повторные попытки. Без логирования вы не узнаете, сколько запросов было повторено, какие ошибки возникали и насколько эффективна ваша Retry Policy. Добавьте метрики: количество повторов, успешность после повтора, распределение задержек. Эти данные помогут настроить оптимальные параметры стратегии под конкретное приложение.