Retry with Backoff
Wiederholen mit wachsenden Pausen
Die Idee und ihr Nutzen
Ein Kunde meldet im Kundenportal seiner Versicherung einen Sturmschaden, Fall 4711. Das Kundenportal fragt beim Vertragsdienst, einem anderen Programm, ob der Vertrag des Kunden solche Schäden abdeckt. Der Vertragsdienst ist gerade überlastet und antwortet mit einer Fehlermeldung. Das Kundenportal fragt dann nicht sofort erneut, sondern wartet vor jedem neuen Versuch länger als vor dem vorigen, damit sich der Vertragsdienst erholen kann. Die Pausen dauern zum Beispiel eine, dann zwei, dann vier Sekunden. Zu jeder Pause kommt ein kleiner, zufällig gewählter Anteil hinzu, aus einer Sekunde werden so etwa 1,2 oder 1,4 Sekunden, damit die Wiederholungen vieler Kunden nicht im selben Augenblick eintreffen. Nach einer festgelegten Zahl von Versuchen gibt das Kundenportal auf und meldet, dass die Prüfung gerade nicht möglich ist. Dieses Vorgehen heißt Retry with Backoff, auf Deutsch Wiederholen mit wachsenden Pausen.
Wie funktioniert es?
Der Kunde meldet seinen Sturmschaden zu Fall 4711, und das Kundenportal muss die Deckung prüfen. Das Kundenportal fragt beim Vertragsdienst an, ob der Vertrag den Sturmschaden deckt. Der Vertragsdienst antwortet mit dem technischen Fehler „überlastet“. Dieser Fehler ist keine fachliche Aussage über die Deckung, deshalb kommt eine Wiederholung in Frage. Das Kundenportal wartet ungefähr eine Sekunde zuzüglich eines Zufallsanteils und fragt erneut. Auch diese erste Wiederholung scheitert, weil der Vertragsdienst noch überlastet ist. Das Kundenportal wartet nun ungefähr zwei Sekunden, wieder mit Zufallsanteil, und fragt ein zweites Mal erneut. Inzwischen hat sich der Vertragsdienst erholt und meldet „gedeckt“, und der Kunde kann seine Meldung fortsetzen. Wäre auch die zweite Wiederholung gescheitert, hätte das Kundenportal nach etwa vier Sekunden eine dritte Wiederholung unternommen. Mehr als drei Wiederholungen erlaubt die Einstellung des Kundenportals nicht: Die drei Pausen dauern zusammen etwa sieben Sekunden, mit den Antwortzeiten des Vertragsdienstes wartet der Kunde so insgesamt höchstens etwa zehn Sekunden. Länger soll ein Kunde mitten in seiner Schadenmeldung nicht auf eine Rückmeldung warten.
Das Kundenportal entscheidet über jede Wiederholung selbst. Zuerst unterscheidet es, ob eine Antwort ein technischer Fehler oder ein fachliches Ergebnis ist. Nur nach einem technischen Fehler wie „überlastet“ oder einer kurz unterbrochenen Netzverbindung wiederholt das Kundenportal die Anfrage. Ein fachliches Ergebnis wie „nicht gedeckt“ ist eine gültige Antwort und ändert sich durch Wiederholen nicht. Das Verlängern der Pausen von Versuch zu Versuch, hier von einer auf zwei und dann auf vier Sekunden, heißt Backoff. Der Zufallsanteil ist nötig, weil nach einem Unwetter sehr viele Kunden zugleich ihre Schäden melden und jede Meldung in einer eigenen Portalsitzung läuft. Scheitert der erste Versuch vieler Portalsitzungen zur selben Zeit, würden diese Portalsitzungen ohne Zufallsanteil auch ihre Wiederholungen genau gleichzeitig senden, und der Vertragsdienst bekäme erneut auf einen Schlag sehr viele Anfragen.
Scheitert auch der letzte Versuch, gibt das Kundenportal auf und zeigt einen Hinweis wie „Die Deckungsprüfung ist gerade nicht möglich, Ihre Angaben sind gespeichert.“ Das Kundenportal behauptet nicht, der Schaden sei nicht gedeckt, denn diese fachliche Frage ist unbeantwortet geblieben. Schwierig wird es bei einer Zeitüberschreitung, wenn also gar keine Antwort kommt. Der Aufrufer weiß dann nicht, ob der aufgerufene Dienst die Anfrage nie erhalten hat oder ob der Dienst sie ausgeführt hat und nur die Antwort verloren ging. Bei einer reinen Abfrage wie der Deckungsprüfung ist das harmlos. Bei einer Zahlung dagegen könnte eine Wiederholung dieselbe Zahlung doppelt auslösen. Änderungen wiederholt ein Aufrufer deshalb nur, wenn jeder Auftrag eine eindeutige Auftragskennung trägt oder wenn feststeht, dass eine Wiederholung keine doppelte Wirkung hat, etwa weil der Auftrag nur einen festen Wert setzt wie den Status „in Prüfung“ für Fall 4711. An der Auftragskennung erkennt der Empfänger einen doppelt eingegangenen Auftrag.
Retry mit Backoff: wachsende Pausen nach einem Überlastfehler
Wann ist es sinnvoll und wann nicht?
Retry with Backoff lohnt sich
- Der Fehler geht wahrscheinlich von selbst vorüber. Beispiele sind eine Überlastung oder eine kurz unterbrochene Netzverbindung. Nach einem schweren Unwetter ist die Überlastung des Vertragsdienstes meist nach wenigen Sekunden vorbei. Bricht das Kundenportal beim ersten Fehler sofort ab, muss der Kunde seine Meldung neu beginnen, obwohl eine kurze Pause gereicht hätte.
- Der Aufruf lässt sich gefahrlos mehrfach ausführen. Das gilt für eine Abfrage wie die Deckungsprüfung. Es gilt auch für einen Auftrag, der etwas ändert, wenn eine eindeutige Auftragskennung ihn gegen doppelte Ausführung schützt. Ohne Wiederholung scheitert auch ein solcher Aufruf endgültig am ersten kurzen Fehler, obwohl ein zweiter Versuch nichts doppelt auslösen würde.
- Viele Aufrufer treffen zugleich auf denselben überlasteten Dienst. Fragen alle Portalsitzungen sofort und ohne Pause erneut, erhält der Vertragsdienst noch mehr Anfragen und erholt sich noch langsamer.
Retry with Backoff ist nicht das Richtige
- Eine Zahlung hat keine eindeutige Auftragskennung. Eine Wiederholung könnte dem Kunden zweimal Geld auszahlen. Dann gibt der Aufrufer jeder Zahlung zuerst eine eindeutige Auftragskennung mit, und der Empfänger führt nach Idempotency einen Auftrag mit einer schon bekannten Kennung nicht noch einmal aus. Erst danach darf der Aufrufer eine Zahlung wiederholen, ohne dass der Kunde zweimal Geld erhält.
- Der Fehler behebt sich durch Warten nicht. Beispiele sind ungültige Eingaben oder fehlende Berechtigungen. Das Kundenportal zeigt den Fehler dann sofort an, statt zu wiederholen. So wartet der Kunde nicht bis zu zehn Sekunden auf Wiederholungen, die alle dieselbe Fehlermeldung liefern.
- Eine Störung dauert voraussichtlich lange. Die Wiederholungen verlängern dann nur die Wartezeit des Kunden und belasten den gestörten Dienst. Dann baut das Team des Kundenportals einen Circuit Breaker ein, einen Programmteil, der nach mehreren gescheiterten Anfragen eine Zeit lang keine Anfrage mehr an den gestörten Dienst durchlässt. Das Kundenportal meldet dem Kunden dann sofort, dass die Prüfung gerade nicht möglich ist. Der gestörte Dienst erhält in dieser Zeit weder Anfragen noch Wiederholungen.
- Die Deckungsprüfung muss nicht sofort während der Meldung erfolgen, und Störungen können länger dauern, als ein Kunde zu warten bereit ist. Dann speichert das Kundenportal die Angaben und legt einen Prüfauftrag in eine Warteschlange, wie es Messaging beschreibt. Eine Warteschlange ist eine Liste von Aufträgen, die ein anderes Programm nacheinander abarbeitet. Der Vertragsdienst holt den Prüfauftrag ab, sobald er wieder Anfragen bearbeiten kann, und der Kunde schließt seine Meldung ab, ohne darauf zu warten. Das Ergebnis der Deckungsprüfung zeigt das Kundenportal dem Kunden später an.
Nachteile und typische Fehler
Zu viele Wiederholungen verbrauchen Rechenzeit, verlängern die Wartezeit des Kunden und können einen überlasteten Dienst zusätzlich belasten. Zahl der Versuche, Länge der Pausen und Höchstwartezeit müssen deshalb dazu passen, wie lange ein Kunde höchstens warten soll und wie viele Anfragen der aufgerufene Dienst bewältigt. Sollen auch Änderungen wiederholt werden, muss der Empfänger jede Auftragskennung speichern und bei jedem Auftrag prüfen, ob die Kennung schon gespeichert ist. Fragt der Vertragsdienst für die Deckungsprüfung seinerseits eine Vertragsdatenbank ab, müssen die Teams von Kundenportal und Vertragsdienst festlegen, welches der beiden Programme wiederholt.
Typische Fehler und woran man sie erkennt:
- Doppelte Ausführung: Der Empfänger führt eine Zahlung aus, doch seine Antwort an den Aufrufer geht verloren. Der Aufrufer wartet bis zur Zeitüberschreitung und wiederholt die Zahlung. Ohne Schutz gegen doppelte Ausführung geht die Zahlung dann zweimal hinaus. Erkennbar ist das an zwei gleichen Zahlungen zum selben Schaden kurz hintereinander.
- Vervielfachte Wiederholungen: Der Vertragsdienst fragt für die Deckungsprüfung seinerseits eine Vertragsdatenbank ab, und die Vertragsdatenbank ist überlastet. Der Vertragsdienst versucht jede Abfrage bis zu dreimal, also mit dem ersten Versuch und zwei eigenen Wiederholungen. Danach meldet der Vertragsdienst dem Kundenportal „überlastet“. Das Kundenportal schickt dieselbe Anfrage daraufhin noch dreimal an den Vertragsdienst. Aus einer Anfrage des Kundenportals werden so bis zu vier mal drei, also zwölf Abfragen an die überlastete Vertragsdatenbank. Wiederholungen dürfen deshalb nur in einem der beiden Programme festgelegt sein. Erkennbar ist das an einem Vielfachen der üblichen Abfragen bei der Vertragsdatenbank, sobald eine Störung beginnt.
- Wiederholung ohne Zufallsanteil: Der erste Versuch vieler Portalsitzungen scheitert zur selben Zeit. Ohne Zufallsanteil wiederholen diese Portalsitzungen genau gleichzeitig. Erkennbar ist das an Lastspitzen beim Vertragsdienst ungefähr eine, drei und sieben Sekunden nach Beginn der Störung.
- Technischer Fehler als fachliche Antwort: Das Kundenportal meldet nach dem letzten gescheiterten Versuch „nicht gedeckt“ statt „Prüfung gerade nicht möglich“. Erkennbar ist das an Kunden, denen während einer Überlastung des Vertragsdienstes ihr Schaden als nicht gedeckt angezeigt wurde.
Weiterführend
Verwandte Ansätze
- Timeout: begrenzt, wie lange das Kundenportal auf eine einzelne Antwort des Vertragsdienstes wartet. Erst nach dieser Zeitgrenze steht fest, dass der Versuch gescheitert ist und eine Wiederholung infrage kommt.
- Fallback: legt fest, was das Kundenportal nach dem letzten gescheiterten Versuch zeigt, etwa den Hinweis, dass die Angaben gespeichert sind.
Quellen
- Microsoft: Retry pattern: beschreibt vorübergehende Fehler, Wiederholungen nach wachsenden Pausen, die Begrenzung der Versuche, die Gefahr doppelter Wirkung bei nicht idempotenten Aufrufen und die Vervielfachung, wenn mehrere Stufen wiederholen.
- Marc Brooker: Timeouts, retries, and backoff with jitter: Beitrag aus der Amazon Builders' Library, der Zeitgrenzen, begrenzte Wiederholungen mit wachsenden Pausen und Zufallsanteil sowie die Regel begründet, nur auf einer Stufe der Aufrufkette zu wiederholen.
- Marc Brooker: Exponential Backoff And Jitter: zeigt mit Messungen, dass wachsende Pausen allein die Wiederholungen vieler Aufrufer noch bündeln und erst ein Zufallsanteil sie gleichmäßig verteilt.