Retry Storm
Ein Retry Storm entsteht, wenn viele Clients bei gemeinsamer Störung gleichzeitig wiederholen. Der zusätzliche Verkehr kann die belastete Abhängigkeit weiter überfordern.
- LastverstärkungJede Ebene wiederholt, die Last multipliziert sich.
- LimitWeniger Versuche je Ebene bremsen die Welle.
- Jitter und QueueZufällige Pausen und eine Queue verteilen den Rest.
Einordnung
Warum das wichtig ist
Bei einer Störung wiederholen viele Clients gleichzeitig, und das Gateway wiederholt zusätzlich. Die Last wächst genau dann, wenn sich der Anbieter erholen müsste. Retry und Backpressure vertiefen eigene Bausteine.
Dieser Baustein behandelt koordinierte Retry-Last. Retry definiert Regeln eines Clients; Backpressure reguliert Zufluss und Queue-Kapazität.
Auf einen Blick · Wiederholungen verstärken die Last
Retry-Last: Clients × Versuche je Ebene
Nach einer kurzen Unterbrechung senden Shop-Clients und Gateway gleichzeitig Zahlungsstatusabfragen. Eine begrenzte Queue und zufällige Pausen verteilen den erneuten Verkehr.
So liest du das Bild
- Lastverstärkung Die Last ist Clients × 3 × 3; bei 1.000 Clients sind das 9.000 Anfragen.
- Limit Mit Schalter: nur 2 Versuche je Ebene, die Verstärkung sinkt von ×9 auf ×4.
- Jitter und Queue Mit Schalter bleibt die Last bei höchstens 1.500 Anfragen unter der Kapazität.
Nutzen & Grenzen
Hilft, wenn
- Viele gleichartige Aufrufer können nach einer gemeinsamen Störung synchronen Zusatzverkehr erzeugen.
- Unabhängige Retry-Regeln in mehreren technischen Schichten brauchen ein gemeinsames Lastbudget.
Grenzen
- Backoff ohne Obergrenze verlängert Fehler und Ressourcenbindung; begrenze Versuche und Gesamtzeit je Auftrag.
- Zusätzliche Instanzen entlasten nichts, wenn sie denselben Speicher oder Zahlungsanbieter belasten; bewerte den gemeinsamen Engpass.
- Jitter verteilt Wiederholungen, verhindert aber keine Überlast; kombiniere ihn mit Backpressure und einem Breaker.
In der Praxis
- Versuche end-to-end erfassen. Zähle ursprüngliche Aufrufe und Wiederholungen an den beteiligten Schichten und leite die maximale Vervielfachung ab. Halte pro Operation fest, wo ein neuer Versuch ausgelöst wird. Das Ergebnis ist ein Gesamtbild zusätzlicher Last.
- Gemeinsames Retry-Budget festlegen. Begrenze Versuchsanzahl und Gesamtzeit, verteile Wartezeiten mit Jitter und definiere eine Rate für Wiederholungsverkehr. Prüfe die Grenze gegen reguläre Last und Abhängigkeitskapazität. Damit wird die zusätzliche Last planbar.
- Erholung dosieren und erproben. Lege fest, wie aufgestaute Arbeit nach einer Störung freigegeben wird und welche Signale den nächsten Schritt erlauben. Simuliere synchrone Wiederverbindung unter Last. Das Ergebnis zeigt, ob Regeln die Erholung schützen oder erneut überlasten.
Ausführliche Erklärung lesen
Ein Retry Storm entsteht, wenn viele Aufrufer im selben Zeitraum wiederholen oder mehrere Schichten die Versuche multiplizieren. Die zusätzliche Last trifft eine Abhängigkeit während ihrer Störung und kann den Ausfall verlängern. Begrenzte Versuche, Backoff und Jitter dämpfen Synchronisierung; ein gemeinsames Budget ergänzt die Regeln einzelner Retry. Ein Circuit Breaker kann Folgeaufrufe bei einem anhaltenden Fehlerbild zeitweise abweisen.
Nach einer Störung kann aufgestaute Arbeit weiterhin einen plötzlichen Wiederanlauf erzeugen. Deshalb sind Lastkontingente, Rate Limits und stufenweise Wiederfreigabe Teil der Betriebsbetrachtung. Retries müssen über den gesamten Anfragepfad gezählt werden, einschließlich Clientbibliotheken und Gateways. Autoscaling hilft nur, wenn zusätzliche Instanzen nicht denselben erschöpften Engpass beanspruchen.
Thundering Herd bezeichnet den verwandten Fall, dass viele Wartende gleichzeitig auf dasselbe Ereignis reagieren und eine Ressource überlasten.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Wie hoch ist die Last am Anbieter bei 500 Clients ohne Schalter, und wie bei eingeschaltetem Schalter?
Lösung mit Begründung ansehen
Ohne Schalter 4.500 Anfragen (500 × 3 × 3), über der Kapazität von 2.000. Mit Schalter 1.500 Anfragen.
AnwendenAuf eine neue Lage übertragen
Nach einer kurzen Unterbrechung fragen viele Clients den Zahlungsstatus zu B-1042 und anderen Bestellungen ab. Wie vermeidest du die Spitze?
Lösung mit Begründung ansehen
Versuche über ein gemeinsames Zeitbudget begrenzen und mit Jitter verteilen. Eine begrenzte Queue hält den Zufluss zum Anbieter innerhalb ihrer Kapazität.
BewertenEine Alternative abwägen
Nur die Clients wiederholen, das Gateway nicht mehr. Was spricht dafür, was dagegen?
Lösung mit Begründung ansehen
Dafür: Die Verstärkung über zwei Ebenen entfällt. Dagegen: Das Gateway fängt kurze Störungen nicht mehr ab, und jeder Client muss die abgestimmten Limits einhalten.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- AWS – Timeouts, retries, and backoff with jitter (öffnet in neuem Tab)Erklärt Timeouts, begrenzte Wiederholungen und Jitter anhand verteilter Ausfälle.
- Microsoft – Retry Storm antipattern (öffnet in neuem Tab)Beschreibt Verstärkung von Überlast durch unkoordinierte Wiederholungen.
- AWS – Exponential Backoff and Jitter (öffnet in neuem Tab)Vergleicht Backoff- und Jitter-Varianten anhand ihrer Lastwirkung.