Retry
Retry sendet einen fehlgeschlagenen Aufruf erneut, wenn der Fehler vorübergehend ist und die Operation sicher wiederholbar bleibt. Begrenzung und Pause halten die zusätzliche Last kontrollierbar.
- BackoffPausen wachsen mit jedem Versuch.
- JitterZufälliger Versatz entzerrt Clients.
- GleichschrittGleichzeitige Wiederholungen bilden Lastspitzen.
Einordnung
Warum das wichtig ist
Vorübergehende Fehler verschwinden oft von selbst, dauerhafte nicht. Wer sofort oder im festen Takt wiederholt, trifft den Dienst oft gleichzeitig wieder. Wachsende, gestreute Pausen geben ihm Luft. Timeout und Retry Storm vertiefen.
Dieser Baustein beschreibt Wiederholungsregeln für einzelne Aufrufe. Retry Storm betrachtet die gemeinsame Last vieler Clients; Idempotenz schützt fachliche Wirkungen.
Auf einen Blick · Wiederholung mit wachsender Wartezeit
Vier Wiederholstrategien im Vergleich
Der Shop lädt nach einem kurzen Verbindungsfehler den Warenkorb erneut. Er wiederholt begrenzt und zeigt nach dem letzten Versuch den gespeicherten Warenkorbstatus.
So liest du das Bild
- Backoff „Exponentieller Backoff“ zeigt Versuche bei 200, 600, 1.400 und 3.000 ms.
- Jitter Bei „Backoff mit Jitter“ liegt „höchstens gleichzeitig“ bei 1 statt 3.
- Gleichschritt Bei „Sofort wiederholen“ landen alle drei Clients zum selben Zeitpunkt.
Zeit nach dem ersten Fehler
höchstens gleichzeitig: 3 von 3Alle drei Clients senden bei 20, 40, 60 und 80 ms zugleich. Der kranke Dienst bekommt kaum Atempause.
Zeiten illustrativ
Nutzen & Grenzen
Hilft, wenn
- Wiederholungen passen zu kurzzeitigen technischen Fehlern mit realistischer Aussicht auf spätere erfolgreiche Ausführung.
- Sichere Operationen oder stabile Wiedererkennung erlauben eine kontrollierte Wiederholung desselben Vorgangs.
Grenzen
- Dauerhafte Fehler bleiben nach jedem Versuch bestehen; klassifiziere sie als endgültig und gib sie ohne weitere Wiederholung an die Fehlerbehandlung.
- Wiederholt der Shop einen Zahlungsaufruf, kann P-731 doppelt wirken; sichere ihn mit Idempotenz und dem Schlüssel pay-B-1042.
- Mehrere Retry-Schichten vervielfachen die Last; lege eine Schicht fest und prüfe das Zusammenspiel in Retry Storm.
In der Praxis
- Fehlerklassen festlegen. Unterscheide vorübergehende technische Störungen, dauerhafte Ablehnungen und unklare Ausgänge. Weise jeder Klasse eine Wiederholungsregel und einen Abbruchpfad zu. Das Ergebnis ist eine konsistente Entscheidung, die Aufrufer und Betrieb gleich behandeln können.
- Sichere Wiederholung bestimmen. Prüfe, ob die Operation ohne doppelte Wirkung erneut ausführbar ist oder der Empfänger denselben Auftrag wiedererkennt. Halte diese Voraussetzung zusammen mit dem Auftragsschlüssel fest. Damit bleibt ein erneuter Versand auf denselben fachlichen Vorgang bezogen.
- Zeit und Versuche begrenzen. Lege maximale Zahl, Backoff, Jitter und gemeinsame Deadline fest und messe ihre Auslastung. Definiere zugleich, welche Antwort bei ausgeschöpftem Budget entsteht. Das Ergebnis ist eine Obergrenze für zusätzliche Last und Wartezeit.
Ausführliche Erklärung lesen
Retry wiederholt eine fehlgeschlagene Operation, wenn die erkannte Fehlerklasse eine vorübergehende Störung erwarten lässt. Vor jedem Versuch müssen Sicherheit der Wiederholung, verbleibende Deadline und maximale Anzahl zusammenpassen. Eine dauerhafte fachliche Ablehnung benötigt eine andere Behandlung. Für Nebenwirkungen ist die Abgrenzung zu Idempotenz wichtig; die Wartezeit folgt dem gemeinsamen Timeout-Budget.
Backoff vergrößert die Pausen, Jitter verteilt viele Versuche zeitlich. Ein begrenztes Retry-Budget schützt die Abhängigkeit und hält die Gesamtdauer vorhersehbar. Retry steuert, ob und wann erneut gesendet wird; es entscheidet nicht selbst, ob der Empfänger den ersten Versuch bereits ausgeführt hat. Diese Klärung gehört zum Auftragszustand und zur passenden Wiedererkennung.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Wann liegt bei exponentiellem Backoff der dritte Versuch, und wie viele Clients treffen dann gleichzeitig ein?
Lösung mit Begründung ansehen
Bei 1.400 ms nach dem ersten Fehler, und alle drei Clients treffen gleichzeitig ein.
AnwendenAuf eine neue Lage übertragen
Drei Clients rufen nach demselben Fehler den Warenkorb ab. Die Spitze soll von 3 auf 1 sinken. Welche Strategie wählst du?
Lösung mit Begründung ansehen
Backoff mit Jitter. Die zufälligen Faktoren zwischen 0,5 und 1,0 verteilen die Versuche, sodass höchstens einer zugleich eintrifft.
BewertenEine Alternative abwägen
Der Team-Vorschlag lautet: exponentieller Backoff ohne Jitter genügt. Was spricht dafür, was dagegen, was empfiehlst du?
Lösung mit Begründung ansehen
Dafür: einfach und vorhersagbar. Dagegen: Alle Clients bleiben synchron, die Spitze bleibt bei 3 und wiederholt sich bei jedem Versuch. Empfehlung: Jitter ergänzen, Versuche und Gesamtzeit begrenzen und nur sicher wiederholbare Aufrufe erneut senden.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Microsoft – Retry pattern (öffnet in neuem Tab)Beschreibt Einsatzgrenzen und Wiederholungsstrategien bei vorübergehenden Fehlern.
- AWS – Timeouts, retries, and backoff with jitter (öffnet in neuem Tab)Erklärt Timeouts, begrenzte Wiederholungen und Jitter anhand verteilter Ausfälle.
- AWS – Making retries safe with idempotent APIs (öffnet in neuem Tab)Zeigt, wie Idempotenz doppelte Nebenwirkungen wiederholter Aufrufe verhindert.