Retry Policy in der mobilen Entwicklung — Wesen, Strategien und Prinzipien

Was ist Retry Policy?

Retry Policy — eine Softwarestrategie, die das Client-Verhalten bei einem fehlgeschlagenen Netzwerkrequest definiert: Welche Fehler sollten wiederholt werden, wie oft, mit welcher Verzögerung und wann sollten Versuche abgebrochen werden. In mobilen Anwendungen ist die Wiederholungsrichtlinie aufgrund der Instabilität mobiler Netze und möglicher temporärer Serverausfälle von entscheidender Bedeutung.

Eine grundlegende Retry Policy umfasst drei Parameter: maximale Anzahl von Wiederholungen (maxRetries), anfängliche Verzögerung (baseDelay) und die Backoff-Strategie. Zusätzlich kann eine Liste von HTTP-Statuscodes angegeben werden, auf die mit einer Wiederholung reagiert werden soll, sowie ein Timeout zum Abbrechen aller Versuche.

Laut Martin Kleppmanns Buch „Designing Data-Intensive Applications“ sind 50% der Ausfälle in verteilten Systemen vorübergehend und können durch eine Wiederholung behoben werden. Dies macht die Retry Policy zu einer der effektivsten und kostengünstigsten Methoden zur Verbesserung der Fehlertoleranz mobiler Anwendungen ohne Änderungen an der Serverarchitektur.

Welche Fehler sollten wiederholt werden

Temporäre Fehler (wiederholbar) sind die einzige Art von Ausfällen, auf die eine Retry Policy reagieren sollte. Dazu gehören Verbindungszeitüberschreitungen (SocketTimeoutException), temporäre Serververfügbarkeit (HTTP 503, 502) und DNS-Fehler. Permanente Fehler — HTTP 400, 401, 403, 404 — sollten nicht wiederholt werden, da sie auf ein Problem mit der Anfrage hinweisen, nicht auf das Netzwerk oder den Server.

Laut AWS Architecture Blog ist die korrekte Klassifizierung von Fehlern in wiederholbar und nicht wiederholbar die wichtigste Entscheidung beim Entwurf einer Retry Policy. Die Wiederholung einer nicht idempotenten Anfrage mit HTTP 401 kann zur Kontosperrung führen, und die Wiederholung von HTTP 400 kann doppelte Daten erzeugen. Konfigurieren Sie die Liste der zu wiederholenden Codes immer explizit.

Grundlegende Wiederholungsstrategien

Festes Intervall — die einfachste Strategie: Jede Wiederholung erfolgt nach dem gleichen Zeitintervall. Bei einer Verzögerung von 2 Sekunden wiederholt die Anwendung die Anfrage beispielsweise nach 2, 2, 2 Sekunden. Das feste Intervall ist einfach zu implementieren und vorhersagbar, erzeugt aber bei massiven Ausfällen eine gleichmäßige Serverlast.

Inkrementelles Intervall — die Verzögerung steigt mit jeder Wiederholung linear an: erste Wiederholung nach 1 Sekunde, zweite nach 2, dritte nach 3 und so weiter. Diese Strategie gibt dem Server bei wiederholten Ausfällen mehr Zeit zur Erholung, ist aber für viele gleichzeitig ausfallende Clients immer noch vorhersagbar.

Die Wahl der Strategie hängt von der Art der Anwendung ab. Für Hintergrundaufgaben zur Datensynchronisation auf mobilen Geräten ist die exponentielle Strategie mit Jitter optimal — sie bietet die höchste Erfolgswahrscheinlichkeit bei minimaler Belastung von Server und Benutzergerät.

Exponentielles Backoff und Jitter

Exponentielles Backoff — eine Strategie, bei der sich die Verzögerung zwischen Wiederholungen mit jedem Versuch verdoppelt. Bei einer anfänglichen Verzögerung von 1 Sekunde beträgt die Verzögerungssequenz 1, 2, 4, 8, 16 Sekunden. Dies gibt dem Server exponentiell wachsende Erholungszeit.

Jitter — eine zufällige Abweichung der Verzögerung, die gleichzeitige Wiederholungsanfragen von mehreren Clients verhindert (Thundering-Herd-Problem). Ohne Jitter würden tausend Clients mit derselben Retry Policy gleichzeitig Anfragen wiederholen und eine Spitzenlast auf dem Server erzeugen. Jitter verteilt die Wiederholungen zeitlich.

Implementierung in Kotlin mit Coroutinen

Kotlin-Coroutinen ermöglichen die Implementierung von exponentiellem Backoff mit Jitter ohne Blockierung des Hauptthreads. Die Funktion retry aus kotlinx-coroutines nimmt eine Wiederholungsbedingung und einen Block mit dem Anforderungstext entgegen und verwaltet Verzögerungen und Versuchsanzahlen automatisch.

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!!)
}

Die Funktion executeWithRetry nimmt einen Lambda mit einem Netzwerkaufruf entgegen und führt ihn mit exponentiellem Backoff und Jitter aus. Wenn der Fehler nicht wiederholbar ist oder die maximale Anzahl von Versuchen überschritten wird, gibt die Funktion einen Fehler zurück. Die Verzögerung wird mit einem Zufallsfaktor von 0,5 bis 1,5 multipliziert, um eine gleichmäßige Verteilung der Wiederholungen zu erreichen.

Circuit Breaker und Stoppen von Wiederholungen

Circuit Breaker — ein Entwurfsmuster, das endlose Wiederholungsanfragen bei längerer Dienstverfügbarkeit verhindert. Wenn die Fehleranzahl einen Schwellenwert überschreitet, wechselt der Circuit Breaker in den Zustand OPEN und gibt sofort einen Fehler zurück, ohne die Anfrage auszuführen, wodurch der Server Zeit zur Erholung erhält.

In mobilen Anwendungen ist der Circuit Breaker besonders nützlich, wenn eine API aufgrund geplanter Wartungsarbeiten oder Netzwerkausfällen des Betreibers nicht verfügbar ist. Ohne ihn würde die Anwendung Batterie und Traffic durch endlose Wiederholungsversuche verbrauchen, die Benutzererfahrung beeinträchtigen und die Akkulaufzeit des Geräts verkürzen.

Zustandsdiagramm des Circuit Breakers

Der Circuit Breaker hat drei Zustände: CLOSED (Normalbetrieb, Anfragen werden ausgeführt), OPEN (Ausfall, Anfragen werden blockiert) und HALF_OPEN (Testanfrage zur Überprüfung der Wiederherstellung). Nach einem bestimmten Timeout im Zustand OPEN wechselt der Schalter zu HALF_OPEN und führt eine Anfrage aus — bei Erfolg kehrt er zu CLOSED zurück, bei Fehlschlag zu 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
        }
    }
}

Die Implementierung des Circuit Breakers in Kotlin enthält einen Fehlerzähler und einen Wiederherstellungs-Timer. Die Methode protect überprüft den aktuellen Zustand vor der Ausführung der gekapselten Anfrage und aktualisiert den Fehlerzähler bei Ausfällen. Nach Erreichen des failureThreshold werden alle Anfragen sofort abgelehnt, bis timeoutMs abläuft.

Retry Policy in mobilen Anwendungen

Mobile Netze haben Eigenschaften, die die Retry Policy besonders wichtig machen. Wechsel zwischen WLAN und mobilen Daten, Signalverlust in U-Bahnen und Tunneln, vorübergehende Sperren auf Betreiberebene — all diese Szenarien führen zu Anfragefehlern, die durch Wiederholungen erfolgreich behoben werden können.

Unter Android bieten die Bibliothek Retrofit und OkHttp einen integrierten Wiederholungsmechanismus über Interceptor. Unter iOS wird die Aufgabe über URLSessionConfiguration und benutzerdefinierte Delegierung gelöst. Für die plattformübergreifende Entwicklung verfügt Ktor (KMP) über integrierte Wiederholungsunterstützung mit konfigurierbaren Strategien.

Implementierung unter iOS mit Combine

Combine — Apples Framework für reaktive Programmierung. Der Operator retry in Combine wiederholt den Publisher bei einem Fehler eine bestimmte Anzahl von Malen, erlaubt jedoch nicht die Konfiguration der Verzögerung zwischen Wiederholungen. Für eine vollständige Retry Policy wird eine benutzerdefinierte Kombination aus catch und flatMap mit Verzögerung verwendet.

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()
    }
}

Die Erweiterung retryWithBackoff für Publisher in Combine implementiert exponentielles Backoff durch rekursive Aufrufe mit abnehmendem Zähler und verdoppelter Verzögerung. Der Operator delay erzeugt eine Pause zwischen Wiederholungen, während catch den Fehler abfängt und entscheidet, ob erneut versucht oder ein Fehler zurückgegeben werden soll.

Häufige Fehler bei Retry Policy

Der erste Fehler — Anfragen wiederholen, ohne die Idempotenz zu überprüfen. Wenn der Server eine Ressource erstellt hat, aber aufgrund eines Netzwerkfehlers keine Bestätigung zurückgegeben hat, erzeugt eine Wiederholung ein Duplikat. Verwenden Sie bei POST-Anfragen immer einen Idempotenz-Schlüssel (Idempotency-Key) im Header oder wechseln Sie zur Wiederholung nur für GET, PUT und DELETE.

Der zweite Fehler — endloses Wiederholen. Legen Sie immer eine maximale Anzahl von Versuchen fest (3–5 für mobile Anwendungen) und ein Gesamt-Timeout für alle Versuche. Endlose Wiederholungen entladen den Akku und erzeugen eine parasitäre Serverlast, insbesondere bei Datenbankmigrationen oder API-Änderungen.

Der dritte Fehler — den Kontext der Anwendung ignorieren. Wenn der Benutzer die Anwendung geschlossen oder in den Hintergrund versetzt hat, sollten aktive Retry Policies ordnungsgemäß abgebrochen werden. Verwenden Sie Coroutinen mit SupervisorScope oder Combine mit dem UI-Lebenszyklus für den automatischen Abbruch von Wiederholungen beim Schließen des Bildschirms.

Der vierte Fehler — Wiederholungsversuche nicht protokollieren. Ohne Protokollierung erfahren Sie nicht, wie viele Anfragen wiederholt wurden, welche Fehler aufgetreten sind und wie effektiv Ihre Retry Policy ist. Fügen Sie Metriken hinzu: Anzahl der Wiederholungen, Erfolg nach Wiederholung, Verteilung der Verzögerungen. Diese Daten helfen, die optimalen Strategieparameter für Ihre spezifische Anwendung einzustellen.