Wiederholungen und Backoff

Die wichtigsten Befehle zum Merken

• curl --retry 2 — höchstens zwei Wiederholungen nach dem Erstversuch erlauben.
• curl --retry-max-time 10 — das Startzeitfenster für Wiederholungen begrenzen.

Befehle und Optionen

Befehl oder Option	Bedeutung
--silent --show-error	Fortschritt ausblenden, Fehlerdiagnosen behalten.
--fail-with-body	HTTP-Fehler als Fehler melden und Antwortinhalt behalten.
--connect-timeout 1 --max-time 3	Aufbau auf eine, jeden Versuch auf drei Sekunden begrenzen.
--retry 2	Passende vorübergehende Fehler zweimal wiederholen: maximal drei Versuche.
--retry-max-time 10	Nach Überschreiten des Wiederholungsfensters keine neuen Retries starten.
-i	HTTP-Antwortheader mit ausgeben.
printf … "$?"	Unmittelbar danach den finalen curl-Status zeigen.

Das Fenster ist keine harte Gesamtdauer: Ein laufender Versuch darf darüber hinaus enden. Curl verwendet seine Verzögerungsregeln und berücksichtigt passende Retry-After-Antworten.

Die entscheidenden Konzepte

1. Ein Retry prüft den Nutzen eines weiteren Versuchs

Ein Retry wiederholt eine Operation nach Fehler oder unklarem Ergebnis. Kurze Dienstunterbrechungen oder Netzprobleme können dadurch ohne Benutzereingriff überwunden werden.

Nicht jeder Fehler ist vorübergehend. Falsche Zugangsdaten oder unzulässige Anfragen werden durch Wiederholung selten richtig. Bestimme geeignete Fehler und bezahlbare Versuchszahl. Jeder Versuch erzeugt zusätzliche Arbeit bei Aufrufer und Abhängigkeit.

2. Backoff gibt Zeit zur Erholung

Sofortige Wiederholungen können einen angeschlagenen Dienst bedrängen. Backoff verteilt Versuche zeitlich; exponentielles Backoff erhöht Abstände bis zu einer Grenze.

Jitter variiert Abstände zwischen Clients, damit nicht alle gleichzeitig zurückkehren. Einheitliche feste Verzögerungen können Lastspitzen synchronisieren. Das curl-Beispiel zeigt begrenzte eingebaute Retries, keine zufallsverteilte Produktionsrichtlinie.

3. Idempotenz bestimmt sichere Wiederholbarkeit

Eine idempotente Operation hat bei Wiederholung denselben beabsichtigten Effekt. Antworten müssen nicht bytegleich sein. Eine Fehlerantwort beweist außerdem keinen ausgebliebenen Effekt.

Für etwa Bestellerstellung braucht es dokumentierte Idempotenz oder Ergebnisabgleich. Eine clientseitige Operationskennung hilft nur bei entsprechender Serversemantik. Ein beliebiger Header mit dem Namen Idempotency-Key erzeugt keinen Duplikatschutz.

4. Retrybudgets gehören zur gesamten Anfrage

Wiederholungen verbrauchen Gesamtzeit. Wiederholen mehrere Schichten unabhängig, können sich nachgelagerte Versuche multiplizieren statt nur addieren.

Bestimme die zuständige Schicht, begrenze Versuche und Warten und stoppe bei nutzlosem Spätergebnis. Bei dauerhaftem Ausfall kann Ablehnen oder Verschieben besser helfen als weiterer Verbrauch knapper Kapazität. Richtlinie, Operation und Fehlermodus müssen zusammenpassen.

Ein kleines Beispiel

Optional: Nutze den zurückgesetzten Testendpunkt mit beschriebener Fehlerfolge. Er muss ein harmloses GET-Ziel sein. Führe printf unmittelbar nach curl aus.

curl --silent --show-error --fail-with-body --connect-timeout 1 --max-time 3 --retry 2 --retry-max-time 10 -i http://localhost:8080/flaky
printf 'curl_exit=%s\n' "$?"

Die erste 503-Antwort erlaubt Wiederholung. Bei anschließendem 200 sollte curl erfolgreich enden. Header oder Diagnosen können mehrere Versuche zeigen; prüfe gegebenenfalls das Requestlog des Testdienstes.

Erfolg allein beweist keinen Retry: Der Dienst könnte vorher wieder gesund gewesen sein. Ein fehlender Endpunkt kann einen nicht wiederholten anderen Fehler liefern. Dateien entstehen nicht. Setze für Wiederholung ausschließlich den eigenen Testzustand zurück.

Merke dir: Wiederhole nur hilfreiche und sichere Operationen mit gemeinsamem Zeitbudget und Abständen, die den Ausfall nicht verschärfen.