Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Wiederholungsverhalten

Wenn eine Anfrage an eine aufgrund eines vorübergehenden Fehlers oder einer Drosselung AWS-Service fehlschlägt, kann das SDK die Anfrage automatisch wiederholen. Auf dieser Seite erfahren Sie, wie Wiederholungen konfiguriert werden und wie sie intern funktionieren.

Wiederholungen konfigurieren

Sie steuern, welche Wiederholungsstrategie das SDK verwendet und wie oft es versucht wird.

Wählen Sie einen Wiederholungsmodus

Der Wiederholungsmodus bestimmt, wie sich das SDK verhält, wenn eine Anforderung fehlschlägt. Drei Modi sind verfügbar: Standard , Adaptiv und Legacy.

Standardmodus (Standard)

Im Standardmodus werden fehlgeschlagene Anfragen mithilfe eines exponentiellen Backoffs mit Jitter wiederholt. Er verwendet kürzere Verzögerungen für vorübergehende Fehler (wie Netzwerk-Timeouts) und längere Verzögerungen für Drosselungsfehler (z. B.). ThrottlingException

Der Standardmodus umfasst ein Wiederholungskontingent, einen Token-Bucket, der bei jedem erneuten Versuch Tokens abzieht und die Token bei erfolgreichen Anfragen wieder auffüllt. Wenn die verfügbaren Token erschöpft sind, gibt das SDK den Fehler zurück, ohne es erneut zu versuchen. Ihre Anwendung schlägt also schnell fehl, anstatt Wiederholungen abzuwarten, die wahrscheinlich nicht erfolgreich sind. Dies hilft auch dabei, Serviceunterbrechungen schneller zu beheben, da der Verkehr bei erneuten Versuchen reduziert wird. Während des normalen Betriebs bleibt das Kontingent voll und hat keine Auswirkung. Das Wiederholungskontingent verzögert oder blockiert niemals die ursprüngliche Anfrage. Nur Wiederholungsversuche sind betroffen. Details hierzu finden Sie unter Kontingent erneut versuchen (Token-Bucket).

Verwenden Sie den Standardmodus, es sei denn, Sie haben einen bestimmten Grund, einen anderen Modus zu wählen.

Adaptiver Modus

Der adaptive Modus umfasst alle Funktionen des Standardmodus sowie einen clientseitigen Ratenbegrenzer. Der Ratenbegrenzer verfolgt Drosselungsreaktionen und passt die Geschwindigkeit an, mit der das SDK Anfragen sendet. Im Gegensatz zum Standardmodus kann der adaptive Modus die erste Anfrage verzögern oder blockieren, nicht nur Wiederholungsversuche, wenn eine Drosselung erkannt wird.

Der Ratenbegrenzer funktioniert pro SDK-Clientinstanz. Alle Anfragen eines Kunden haben dasselbe Ratenlimit, unabhängig davon, auf welche API-Operation oder Ressource sie abzielen.

Wann sollte der adaptive Modus verwendet werden:

Wann Sie den adaptiven Modus nicht verwenden sollten:

Der adaptive Modus wird nicht als allgemeine Standardeinstellung empfohlen.

Legacy-Modus

Der Legacy-Modus ist das Wiederholungsverhalten, das jedes SDK vor der Einführung des Standardmodus verwendet hat. Es beinhaltet kein standardisiertes Wiederholungskontingent. Einige SDKs (wie Java) hatten im Legacy-Modus ihre eigenen Wiederholungsquotenimplementierungen, aber das Verhalten ist nicht in allen SDKs konsistent. Ohne ein standardisiertes Kontingent versucht es ein Client bei Betriebsunterbrechungen weiterhin mit voller Geschwindigkeit. Dadurch werden Threads und Verbindungen bei Anfragen, bei denen es unwahrscheinlich ist, dass sie erfolgreich sind, gebunden, und gleichzeitig wird die Last erhöht, die die Wiederherstellung des Dienstes verzögern kann.

Der Legacy-Modus ist je nach SDKs unterschiedlich. Die Anzahl der Wiederholungen, die Backoff-Zeit, die Anzahl der wiederholbaren Fehler und das Drosselungsverhalten unterscheiden sich je nach Sprache. Code, der vom alten Wiederholungsverhalten abhängt, verhält sich möglicherweise anders, wenn er zwischen SDKs verschoben wird.

Verfügbar in: Java, Python, Ruby, PHP, C++, CLI

Nicht verfügbar in: .NET, Go, Kotlin, Rust, Swift, JavaScript

Der Legacy-Modus ist aus Gründen der Abwärtskompatibilität vorhanden. Wenn Sie derzeit den Legacy-Modus verwenden, wechseln Sie in den Standardmodus.

Versuchen Sie es erneut mit den Einstellungen

Die folgenden Einstellungen steuern das Wiederholungsverhalten. Sie können sie über Umgebungsvariablen, die gemeinsam genutzte Konfigurationsdatei (~/.aws/config) oder die Client-Konfiguration im Code festlegen.

Ein Wert für maximale Versuche von 3 bedeutet, dass das SDK eine erste Anfrage und bis zu zwei Wiederholungsversuche stellt. Setzen Sie die maximale Anzahl an Versuchen auf, 1 um Wiederholungen vollständig zu deaktivieren.

Vorrang der Konfiguration

Wenn Sie dieselbe Einstellung an mehreren Stellen angeben, löst das SDK den Wert anhand der folgenden Rangfolge auf, von der höchsten zur niedrigsten:

Dies folgt der Standardpriorität der AWS SDK-Konfiguration. Ein auf einer höheren Ebene festgelegter Wert überschreibt immer einen auf einer niedrigeren Ebene festgelegten Wert. Wenn Sie ihn beispielsweise AWS_RETRY_MODE=adaptive als Umgebungsvariable festlegen und retry_mode=standard in~/.aws/config, verwendet das SDK den adaptiven Modus.

Language-specific Konfiguration

Die auf dieser Seite (retry_modeundmax_attempts) beschriebenen SDK-übergreifenden Einstellungen funktionieren in allen SDKs. Die API für die Konfiguration von Wiederholungsversuchen im Code variiert jedoch je nach Sprache. Im Entwicklerhandbuch Ihres SDK finden Sie sprachspezifische Konfigurationsoptionen wie benutzerdefinierte Backoff-Strategien, zusätzliche Fehler, die wiederholt werden können, und die Optimierung der Quote für Wiederholungen.

Wie funktionieren Wiederholungen

In diesem Abschnitt wird beschrieben, wie AWS SDKs mit fehlgeschlagenen Anfragen umgehen: welche Fehler lösen Wiederholungsversuche aus, wie lange das SDK zwischen Versuchen wartet und wann es die Wiederholungsversuche beendet.

Was passiert, wenn eine Anfrage fehlschlägt

Wenn Sie einen API-Aufruf über ein AWS SDK tätigen, folgt das SDK dieser Reihenfolge:

Das SDK wiederholt diese Schleife, bis die Anfrage erfolgreich ist, die maximale Anzahl von Versuchen erreicht ist, das Wiederholungskontingent erschöpft ist oder ein Fehler auftritt, der nicht wiederholt werden kann. Der gesamte Vorgang erfolgt automatisch. Ihre Bewerbung sieht entweder eine erfolgreiche Antwort oder einen letzten Fehler.

Welche Fehler werden wiederholt

Das SDK klassifiziert jede fehlgeschlagene Anfrage in eine von drei Kategorien: vorübergehend, drosselnd oder nicht wiederholbar. Diese Klassifizierung bestimmt, ob das SDK die Anfrage erneut versucht und wie lange es wartet, bevor es erneut versucht.

Die Klassifizierung basiert auf dem Fehlercode und dem HTTP-Statuscode in der Serviceantwort. Beispielsweise wird ein HTTP 400 mit dem Fehlercode als vorübergehend RequestTimeout eingestuft und erneut versucht. Ein HTTP 400-Code mit ValidationException wird als nicht wiederholbar eingestuft und sofort zurückgegeben.

Fehlerklassifizierung

Vorübergehende Fehler werden mit einer kurzen Basisverzögerung (50 ms) wiederholt:

Drosselungsfehler werden mit einer längeren Basisverzögerung (1.000 ms) wiederholt:

Non-retryable Fehler (wieAccessDeniedException,ValidationException,ResourceNotFoundException) werden sofort an Ihren Code zurückgegeben.

Drosselungsfehler bedeuten, dass der Dienst Ihre Anfrage aufgrund von Ratenbeschränkungen aktiv abgelehnt hat. Das SDK wartet also länger, bevor es erneut versucht, um dem Service Zeit zu geben, die Kapazität wiederherzustellen. Informationen zu den spezifischen Verzögerungen finden Sie unterWie lange wartet das SDK.

Wie lange wartet das SDK

Das SDK verwendet exponentielles Backoff mit vollem Jitter. Im Durchschnitt wartet jeder Wiederholungsversuch länger als der letzte, wobei die Anfragen nach dem Zufallsprinzip auf mehrere Clients verteilt werden.

Standardverzögerungen nach Fehlertyp

Die Basisverzögerung hängt davon ab, ob es sich um einen vorübergehenden Fehler oder um einen drosselnden Fehler handelt:

Backoff-Formel

Das SDK berechnet jede Verzögerung bei Wiederholungsversuchen anhand dieser Formel:

delay = random(0, 1) × min(20,000 ms, base_delay × 2^retry)

Wobei Folgendes gilt:

Die maximale Backoff-Obergrenze liegt bei 20 Sekunden. Keine einzelne Verzögerung überschreitet 20 Sekunden, unabhängig davon, wie viele Versuche unternommen wurden.

Beispiele, die funktioniert haben

Beispiel 1: Vorübergehender Fehler, maximal 3 Versuche

Die gesamte hinzugefügte Latenz beträgt bei beiden Wiederholungsversuchen im Durchschnitt etwa 75 ms.

Beispiel 2: Drosselungsfehler, maximal 3 Versuche

Die gesamte hinzugefügte Latenz beträgt bei beiden Wiederholungsversuchen im Durchschnitt etwa 1.500 ms.

Beispiel 3: Vorübergehender Fehler, bei Erreichen der Backoff-Obergrenze

Bei einer Basisverzögerung von 50 ms wäre die berechnete Verzögerung vor der Obergrenze wie folgt:

Die Obergrenze wird beim 10. Wiederholungsversuch (11. Versuch) für vorübergehende Fehler wirksam. Bei Drosselungsfehlern mit einer Basis von 1.000 ms wird die Obergrenze beim 6. Wiederholungsversuch wirksam.

Warum Jitter wichtig ist

Der zufällige Multiplikator wird als voller Jitter bezeichnet. Ohne ihn würden alle Clients, die zur gleichen Zeit auf einen Fehler stoßen, es zur gleichen Zeit erneut versuchen, was zu einem Anstieg des Wiederholungsverkehrs führen würde (das Problem der „donnernden Herde“). Full Jitter verteilt Wiederholungsversuche gleichmäßig über das gesamte Backoff-Fenster, sodass der Service ein stetiges Rinnsal von Anfragen erhält, statt synchronisierter Spitzen.

Nehmen wir zum Beispiel an, 1.000 Clients erhalten alle zur gleichen Zeit 503. Bei vollem Jitter werden die ersten Versuche gleichmäßig über ein Fenster von 50 ms verteilt, anstatt dass alle 1.000 Wiederholungen in exakt 50 ms erfolgen.

Server-directed Zeitpunkt der Wiederholungsversuche

Einige AWS-Services enthalten einen x-amz-retry-after Header in den Fehlerantworten. Der Header-Wert ist eine Verzögerung in Millisekunden. Wenn dieser Header vorhanden ist, verwendet das SDK die vom Server angegebene Verzögerung, die auf ein Minimum der berechneten Backoff-Verzögerung und ein Maximum der berechneten Backoff-Verzögerung plus 5.000 ms begrenzt ist. Da das berechnete Backoff selbst auf 20 Sekunden begrenzt ist, beträgt die effektive maximale servergesteuerte Verzögerung 25 Sekunden. Das SDK wendet keinen Jitter auf diesen Wert an, da erwartet wird, dass der Dienst ihn jittert. Dadurch kann der Dienst genau dann kommunizieren, wenn er davon ausgeht, dass Kapazität verfügbar ist.

Kontingent erneut versuchen (Token-Bucket)

Das SDK verwaltet ein internes Token-Budget, das das Verhältnis zwischen erfolgreichen und fehlgeschlagenen Anfragen nachverfolgt. Wenn Fehler weit verbreitet sind, wird das Budget aufgebraucht und das SDK gibt Fehler direkt zurück. Ihre Anwendung schlägt schnell fehl, anstatt auf Wiederholungen zu warten, die wahrscheinlich nicht erfolgreich sein werden. Dadurch wird auch der Datenverkehr bei erneuten Versuchen reduziert, sodass Serviceunterbrechungen schneller behoben werden können.

So funktioniert das Kontingent für Wiederholungen

Das Token-Budget ist zu Beginn voll. Bei jedem erneuten Versuch werden Tokens abgezogen. Wenn ein Wiederholungsversuch erfolgreich ist, stellt das SDK die bei diesem erneuten Versuch verbrauchten Token wieder her. Wenn eine Anfrage beim ersten Versuch erfolgreich ist (keine Wiederholungen erforderlich), stellt das SDK 1 Token wieder her. Wenn das Budget Null erreicht, stoppt das SDK den erneuten Versuch und gibt Fehler direkt an Ihren Code zurück.

Die höheren Kosten für vorübergehende Wiederholungsversuche spiegeln das unterschiedliche Fehlermuster wider. Vorübergehende Fehler wie 500s und Verbindungsausfälle deuten oft auf ein dienstweites Problem hin. In diesen Situationen ist es unwahrscheinlich, dass ein wiederholter Versuch erfolgreich ist. Dies erhöht die Latenz Ihrer Anrufe, belastet Kundenressourcen und kann die Wiederherstellung für alle verzögern. Drosselungsfehler signalisieren, dass der Dienst mehr Zeit benötigt, bevor die Anfrage erfolgreich sein kann. Das SDK wartet zwischen den Wiederholungsversuchen länger, um die Erfolgswahrscheinlichkeit zu erhöhen.

Wann versucht der Kontingentblock erneut

Das Wiederholungskontingent verfolgt die Tokens zu jeder Zeit, blockiert jedoch nur Wiederholungsversuche, wenn das Budget aufgebraucht ist. Während des normalen Betriebs sind fast alle Anfragen erfolgreich und das Budget bleibt voll. Die Quote hat keine beobachtbaren Auswirkungen auf Wiederholungsversuche.

Bei einem erfolgreichen Wiederholungsversuch werden nur die eigenen Token-Kosten (14 oder 5 Token) wiederhergestellt, nicht die Kosten früherer fehlgeschlagener Wiederholungen in derselben Anfrage. Wenn beispielsweise der erste Wiederholungsversuch fehlschlägt und der zweite erfolgreich ist, verliert das Budget netto 14 Token. Das Budget wird am schnellsten aufgebraucht, wenn Wiederholungsversuche alle Versuche erschöpfen, ohne erfolgreich zu sein, aber es wird auch allmählich verbraucht, wenn Anfragen mehrere Wiederholungen erfordern, bevor sie erfolgreich sind.

Bei der Standardeinstellung von maximal 3 Versuchen beginnt das Kontingent zu erschöpfen, wenn mehr als etwa 22% der Anfragen zu anhaltenden vorübergehenden Fehlern führen, oder mehr als etwa 32% bei Drosselungsfehlern. Unterhalb dieser Raten wird das Budget bei erfolgreichen Anfragen schneller aufgefüllt als bei fehlgeschlagenen Wiederholungsversuchen.

Das Startguthaben des Budgets von 500 Token bietet einen Puffer, der kurze Ausfälle auffangen kann. Ein kurzer Anstieg an Fehlern, selbst ein schwerwiegender, blockiert keine Wiederholungsversuche, es sei denn, er hält lange genug an, um den Puffer zu leeren.

Praktische Implikationen

Service-specific Verhalten

DynamoDB

DynamoDB-Clients verwenden optimierte Standardwerte, die für das DynamoDB-Profil mit niedriger Latenz optimiert sind:

Diese Standardeinstellungen gelten sowohl für Amazon DynamoDB- als auch für DynamoDB-Streams.

Long-polling Operationen

Bestimmte AWS Operationen verwenden lange Abfragen. Sie können eine Verbindung offen halten und darauf warten, dass die Arbeit eintrifft. Diese Operationen werden einer speziellen Wiederholungsbehandlung unterzogen:

Spezielles Verhalten: Wenn das Wiederholungskontingent erschöpft ist und Wiederholungsversuche blockiert werden (Schritt 7 inWas passiert, wenn eine Anfrage fehlschlägt), wendet das SDK dennoch eine Backoff-Verzögerung an, bevor der Fehler an Ihren Code zurückgegeben wird.

Dies ist wichtig, da lange Abfragen normalerweise in einer engen Schleife aufgerufen werden. Ihr Code ruft aufReceiveMessage, verarbeitet alle Nachrichten und ruft ReceiveMessage dann sofort wieder auf. Ohne den erzwungenen Backoff würde ein erschöpftes Token-Budget dazu führen, dass das SDK Fehler ohne Verzögerung zurückgibt. Ihr Polling-Loop würde dann sofort die nächste Anfrage senden, was die CPU-Auslastung des Clients in die Höhe treiben und zusätzlichen Traffic generieren würde. Die erzwungene Backoff-Verzögerung unterbricht diesen Zyklus, sodass die Nutzung der Client-Ressourcen und die Abfragerate bei Ausfällen überschaubar bleiben.

Unterstützung von AWS SDKs und Tools

In der folgenden Tabelle ist die Verfügbarkeit des aktualisierten Wiederholungsverhaltens in jedem SDK aufgeführt. SDK-specific Einzelheiten wie Mindestversion, Vorher-Nachher-Standardwerte und Codebeispiele finden Sie unter dem Tracking-Problem. GitHub