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
**Wichtig**
Das auf dieser Seite beschriebene Verhalten muss aktiviert werden, bis es zum Standardverhalten wird. `AWS_NEW_RETRIES_2026=true`In Ihrer Umgebung festgelegt. Ohne diese Einstellung verwendet Ihr SDK ein Wiederholungsverhalten aus der Zeit vor 2026, das sich im Backoff-Timing, in den Kosten für Wiederholungsversuche und in den dienstspezifischen Standardeinstellungen unterscheidet. [Einzelheiten finden Sie im Blogbeitrag zur Ankündigung.](https://aws.amazon.com/blogs/developer/announcing-updated-retry-behavior-for-aws-sdks-and-tools/)
Wenn eine Anfrage an aufgrund eines vorübergehenden Fehlers oder einer Drosselung AWS-Service fehlschlägt, kann das SDK die Anfrage automatisch wiederholen. Auf dieser Seite wird beschrieben, wie Wiederholungen konfiguriert werden und wie sie intern funktionieren.
+ [Konfiguration von Wiederholungsversuchen](#configuring-retries): Wählen Sie einen Wiederholungsmodus, legen Sie die maximale Anzahl der Versuche fest und machen Sie sich mit der Rangfolge der Konfiguration vertraut.
+ [Wie funktionieren Wiederholungsversuche](#how-retries-work): Wiederholungsablauf, Fehlerklassifizierung, Backoff-Formel, Mechanismen für Wiederholungsquoten und dienstspezifisches Verhalten.
## Konfiguration von Wiederholungsversuchen
Sie steuern, welche Wiederholungsstrategie das SDK verwendet und wie oft es es wiederholt.
### Wählen Sie einen Wiederholungsmodus
Der Wiederholungsmodus bestimmt, wie sich das SDK verhält, wenn eine Anfrage fehlschlägt. **Drei Modi sind verfügbar: **Standard**, **Adaptiv** und Legacy.**
| | Standard | Adaptiv | Veraltet |
| --- | --- | --- | --- |
| Kontingent erneut versuchen | Ja | Ja | Variiert je nach SDK |
| Kann die erste Anfrage verzögern | Nein | Ja | Nein |
| Error-type-specific einen Rückzieher | Ja | Ja | Variiert je nach SDK |
| Für alle SDKs standardisiert | Ja | Ja | Nein |
| Empfehlung | Standard für alle Workloads | Single-resource, stark drosselnd, latenztolerant | Nur Abwärtskompatibilität |
#### Standardmodus (Standard)
Der Standardmodus wiederholt fehlgeschlagene Anfragen mithilfe eines exponentiellen Backoffs mit Jitter. Er verwendet kürzere Verzögerungen für vorübergehende Fehler (z. B. 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 bei erfolgreichen Anfragen die Tokens wieder auffüllt. Wenn die verfügbaren Token erschöpft sind, gibt das SDK den Fehler zurück, ohne es erneut zu versuchen, sodass Ihre Anwendung schnell fehlschlägt, anstatt Wiederholungen abzuwarten, deren Erfolg unwahrscheinlich ist. Dies trägt auch dazu bei, dass Serviceunterbrechungen schneller behoben werden, indem der Datenverkehr mit Wiederholungsversuchen reduziert wird. Während des normalen Betriebs bleibt das Kontingent voll und hat keine Auswirkung. Das Wiederholungskontingent verzögert oder blockiert niemals die erste Anfrage. Nur Wiederholungen sind betroffen. Details hierzu finden Sie unter [Kontingent erneut versuchen (Token-Bucket)](#retry-quota-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. Für alle Anfragen von einem Client gilt dasselbe Ratenlimit, unabhängig davon, auf welchen API-Vorgang oder welche Ressource sie abzielen.
**Wann sollte der adaptive Modus verwendet werden:**
+ Ihr Client zielt auf eine einzelne Ressource ab (z. B. eine DynamoDB-Tabelle), und Sie erwarten häufige Drosselungsreaktionen. Dies ist häufig bei automatisierten Workflows, Batch-Prozessoren oder KI-Workloads der Fall, bei denen ein einzelner API-Vorgang mit hohem Volumen aufgerufen wird.
+ Sie möchten, dass das SDK automatisch langsamer wird, wenn der Dienst eine Drosselung signalisiert.
**Wann Sie den adaptiven Modus nicht verwenden sollten:**
+ Ihr Client sendet Anfragen an mehrere Ressourcen oder bedient mehrere Mandanten. Die Drosselung einer Ressource führt dazu, dass der Ratenbegrenzer alle Anfragen von diesem Client verlangsamt, einschließlich Anfragen an nicht betroffene Ressourcen.
+ Sie benötigen eine vorhersehbare Latenz bei der ersten Anfrage.
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) verfügten im Legacy-Modus über eigene Implementierungen für Wiederholungsquoten, aber das Verhalten ist bei allen SDKs nicht einheitlich. Ohne ein standardisiertes Kontingent versucht ein Client bei Serviceunterbrechungen weiterhin mit voller Geschwindigkeit. Dadurch werden Threads und Verbindungen bei Anfragen blockiert, die wahrscheinlich nicht erfolgreich sind, und gleichzeitig wird die Last erhöht, was die Wiederherstellung des Dienstes verzögern kann.
Der Legacy-Modus ist je nach SDKs unterschiedlich. Die Anzahl der Wiederholungen, der Backoff-Timing, die Anzahl wiederholbarer Fehler und das Einschränkungsverhalten unterscheiden sich von Sprache zu Sprache. Code, der vom Verhalten älterer Versionen bei Wiederholungsversuchen abhängt, kann sich anders verhalten, 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
Aus Gründen der Abwärtskompatibilität gibt es den Legacy-Modus. Wenn Sie derzeit den Legacy-Modus verwenden, wechseln Sie in den Standardmodus.
### Versuchen Sie es erneut mit den Einstellungen
Die folgenden Einstellungen steuern das Verhalten bei Wiederholungsversuchen. Sie können sie über [Umgebungsvariablen](environment-variables.md), die [gemeinsam genutzte Konfigurationsdatei](file-format.md) (`~/.aws/config`) oder die Client-Konfiguration im Code festlegen.
| Einstellung | Was es steuert | Umgebungsvariable | Schlüssel der Konfigurationsdatei | Standard |
| --- | --- | --- | --- | --- |
| Wiederholungsmodus | Welche Wiederholungsstrategie soll verwendet werden | AWS\_RETRY\_MODE | retry\_mode | standard |
| Max versucht | Gesamtzahl der Versuche, einschließlich der ersten Anfrage | AWS\_MAX\_ATTEMPTS | max\_attempts | 3(siehe Hinweise) |
Ein Wert für max. Versuche `3` bedeutet, dass das SDK eine erste Anfrage und bis zu zwei Wiederholungen durchführt. Legen Sie die maximale Anzahl der Versuche fest, `1` um Wiederholungen vollständig zu deaktivieren.
**Anmerkung**
Die DynamoDB- und DynamoDB Streams Streams-Clients verwenden standardmäßig die maximale Anzahl von Versuchen. `4` Diese Dienste verwenden eine kürzere Basis-Backoff-Verzögerung (25 ms statt 50 ms), um ihrem Profil mit niedriger Latenz zu entsprechen. Durch den zusätzlichen Versuch ist der maximale Backoff-Wert des letzten Wiederholungsversuchs mit dem anderer Dienste vergleichbar. Sie können dies mit den gleichen Einstellungen aus der vorherigen Tabelle außer Kraft setzen.
### Priorität der Konfiguration
Wenn Sie dieselbe Einstellung an mehreren Stellen angeben, löst das SDK den Wert anhand der folgenden Rangfolge auf, vom höchsten zum niedrigsten Wert:
1. **Explizite Client-Konfiguration im Code.** Ein Wert, der direkt auf dem SDK-Client oder seinem Konfigurationsobjekt festgelegt wurde.
1. **[Umgebungsvariable](environment-variables.md).** Zum Beispiel `AWS_RETRY_MODE` oder `AWS_MAX_ATTEMPTS`.
1. **[Gemeinsam genutzte Konfigurationsdatei](file-format.md).** Geben Sie die `max_attempts` Taste `retry_mode` oder ein`~/.aws/config`.
1. **SDK-Standard.** Die integrierte Standardeinstellung für die Einstellung.
Dies entspricht der [Priorität der AWS Standard-SDK-Konfiguration](settings-reference.md). Ein auf einer höheren Ebene festgelegter Wert hat immer Vorrang vor einem Wert auf einer niedrigeren Ebene. Wenn Sie beispielsweise den Wert `AWS_RETRY_MODE=adaptive` als Umgebungsvariable und `retry_mode=standard` in festlegen`~/.aws/config`, verwendet das SDK den adaptiven Modus.
### Language-specific Konfiguration
Die auf dieser Seite beschriebenen Cross-SDK-Einstellungen (`retry_mode`und`max_attempts`) 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 Kontingentoptimierung für Wiederholungsversuche.
## Wie funktionieren Wiederholungsversuche
In diesem Abschnitt wird beschrieben, wie AWS SDKs mit fehlgeschlagenen Anfragen umgehen: Welche Fehler lösen Wiederholungen aus, wie lange das SDK zwischen den 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:
1. **Nur [adaptiver Modus](#adaptive-mode):** Das SDK überprüft den clientseitigen Ratenbegrenzer. Wenn eine Drosselung erkannt wurde, kann das SDK die Anfrage verzögern oder blockieren, bevor sie gesendet wird.
1. Das SDK sendet die Anfrage an den AWS-Service Endpunkt.
1. Wenn der Dienst eine erfolgreiche Antwort zurückgibt, gibt das SDK das Ergebnis an Ihren Code zurück.
1. *Wenn die Anfrage fehlschlägt, stuft das SDK den Fehler als *vorübergehend*, *drosselnd* oder nicht wiederholbar ein.* Siehe [Welche Fehler werden wiederholt](#which-errors-are-retried).
1. Wenn der Fehler nicht erneut versucht werden kann, gibt das SDK den Fehler sofort an Ihren Code zurück. Es wird kein erneuter Versuch versucht.
1. Wenn der Fehler erneut versucht werden kann, überprüft das SDK, ob die maximale Anzahl von Versuchen erreicht wurde. Wenn ja, gibt es den Fehler an Ihren Code zurück.
1. Das SDK überprüft die[Kontingent erneut versuchen (Token-Bucket)](#retry-quota-token-bucket). Wenn das Token-Budget aufgebraucht ist, versucht das SDK es nicht erneut und gibt den Fehler an Ihren Code zurück. Ausnahme: Denn das SDK wendet immer noch eine Backoff-Verzögerung an[Long-polling Operationen](#long-polling-operations), bevor der Fehler zurückgegeben wird.
1. Das SDK berechnet eine Backoff-Verzögerung auf der Grundlage des Fehlertyps und der Nummer des Wiederholungsversuchs. Siehe [Wie lange wartet das SDK](#how-long-does-the-sdk-wait).
1. Das SDK wartet auf die berechnete Verzögerung und sendet die Anfrage dann ab Schritt 2 erneut.
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 läuft automatisch ab. Bei Ihrer Anwendung wird entweder eine erfolgreiche Antwort oder ein letzter Fehler angezeigt.
### Welche Fehler werden wiederholt
Das SDK unterteilt 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, bis 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 mit `ValidationException` wird als nicht wiederholbar eingestuft und sofort zurückgegeben.
#### Fehlerklassifizierung
**Vorübergehende Fehler** werden mit einer kurzen Basisverzögerung (50 ms) wiederholt:
| Fehlercode |
| --- |
| RequestTimeout |
| RequestTimeoutException |
| InternalError |
| IDPCommunicationError |
| I/O Fehler (Verbindung zurückgesetzt, DNS-Auflösungsfehler, Socket-Timeout) |
| (beliebiges HTTP 500, 502, 503 oder 504 ohne erkannten Fehlercode) |
**Drosselungsfehler** werden mit einer längeren Basisverzögerung (1.000 ms) wiederholt:
| Fehlercode |
| --- |
| Throttling |
| ThrottlingException |
| ThrottledException |
| RequestThrottledException |
| TooManyRequestsException |
| ProvisionedThroughputExceededException |
| TransactionInProgressException |
| LimitExceededException |
| PriorRequestNotComplete |
| RequestThrottled |
| EC2ThrottledException |
| RequestLimitExceeded |
| SlowDown |
| BandwidthLimitExceeded |
**Non-retryable Fehler** (wie`AccessDeniedException`,`ValidationException`,`ResourceNotFoundException`) werden sofort an Ihren Code zurückgegeben.
**Anmerkung**
Ein HTTP 5XX mit einem Drosselungsfehlercode wird als Drosselungsfehler und nicht als vorübergehender Fehler eingestuft, obwohl 5XX-Fehler normalerweise vorübergehend sind. Das SDK sucht zuerst nach dem Fehlercode und greift dann auf den HTTP-Statuscode zurück.
Drosselungsfehler bedeuten, dass der Service Ihre Anfrage aufgrund von Ratenbeschränkungen aktiv abgelehnt hat. Daher wartet das SDK länger, bevor es erneut versucht, dem Service Zeit für die Wiederherstellung der Kapazität zu geben. Die spezifischen Verzögerungen finden Sie unter[Wie lange wartet das SDK](#how-long-does-the-sdk-wait).
### Wie lange wartet das SDK
Das SDK verwendet **exponentiellen Backoff mit vollem Jitter**. Im Durchschnitt wartet jeder Wiederholungsversuch länger als der letzte, wobei die Anfragen von mehreren Clients nach dem Zufallsprinzip verteilt werden.
#### Basisverzögerungen nach Fehlertyp
Die Basisverzögerung hängt davon ab, ob es sich um einen vorübergehenden Fehler oder um einen drosselnden Fehler handelt:
| Fehlertyp | Basisverzögerung | Begründung |
| --- | --- | --- |
| Vorübergehend (ohne Drosselung) | 50 ms | Vorübergehende Fehler werden in der Regel innerhalb von Millisekunden behoben. Eine kurze Basisverzögerung ermöglicht eine schnelle Wiederherstellung. |
| Drosselung | 1.000 ms | Der Service hat für die Anfrage eine Gebührenbegrenzung festgelegt. Eine längere Basisverzögerung gibt Zeit für die Wiederherstellung der Kapazität. |
#### Backoff-Formel
Das SDK berechnet jede Verzögerung beim erneuten Versuch anhand der folgenden Formel:
```
delay = random(0, 1) × min(20,000 ms, base_delay × 2^retry)
```
Wobei Folgendes gilt:
+ `random(0, 1)`gibt einen gleichmäßig verteilten Wert zwischen 0 und 1 zurück
+ `base_delay`ist 50 ms für vorübergehende Fehler oder 1.000 ms für Drosselungsfehler
+ `retry`beginnt bei 0 für den ersten Wiederholungsversuch (den zweiten Anforderungsversuch insgesamt)
**Die maximale Backoff-Obergrenze beträgt 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, max. 3 Versuche**
| Schritt | Was passiert | Delay |
| --- | --- | --- |
| Versuch 1 | Erste Anfrage. Der Dienst gibt HTTP 503 zurück. | (Keine) |
| Versuch 2 | Das SDK wartet zufällig (0, 50 ms). Der Wiederholungsversuch schlägt mit 503 fehl. | 0—50 ms (durchschnittlich \~25 ms) |
| Versuch 3 | Das SDK wartet zufällig (0, 100 ms). Der Wiederholungsversuch ist erfolgreich. | 0—100 ms (durchschnittlich \~50 ms) |
Die gesamte zusätzliche Latenz beträgt bei beiden Wiederholungen durchschnittlich etwa 75 ms.
**Beispiel 2: Drosselungsfehler, max. 3 Versuche**
| Schritt | Was passiert | Delay |
| --- | --- | --- |
| Versuch 1 | Erste Anfrage. Der Service gibt 429 Throttling zurück. | (Keine) |
| Versuch 2 | Das SDK wartet zufällig (0, 1.000 ms). Retry gibt 429 zurück. | 0—1.000 ms (durchschnittlich \~500 ms) |
| Versuch 3 | Das SDK wartet zufällig (0, 2.000 ms). Der Wiederholungsversuch ist erfolgreich. | 0—2.000 ms (durchschnittlich \~1.000 ms) |
Die gesamte zusätzliche Latenz beträgt bei beiden Wiederholungen durchschnittlich etwa 1.500 ms.
**Beispiel 3: Vorübergehender Fehler, bei dem das Backoff-Limit erreicht wird**
Bei einer Basisverzögerung von 50 ms würde die berechnete Verzögerung vor dem Capping wie folgt aussehen:
| Versuchen Sie es erneut | Berechnete maximale Verzögerung | Nach 20 s Kappe |
| --- | --- | --- |
| 1 | 50 ms | 50 ms |
| 2 | 100 ms | 100 ms |
| 5 | 800 ms | 800 ms |
| 9 | 12.800 ms | 12.800 ms |
| 10 | 25.600 ms | 20.000 ms |
Die Obergrenze wird bei vorübergehenden Fehlern bei der 10. Wiederholung (11. Versuch) wirksam. Bei Drosselungsfehlern mit einer Basisgeschwindigkeit von 1.000 ms wird die Obergrenze bei der sechsten Wiederholung wirksam.
**Anmerkung**
Bei der Standardeinstellung von maximal 3 Versuchen (1 erste Anfrage \+ 2 Wiederholungen) wird die Backoff-Obergrenze nie erreicht. In dieser Tabelle wird veranschaulicht, was passiert, wenn Sie den Wert `max_attempts` deutlich über den Standardwert hinaus erhöhen.
#### Warum Jitter wichtig ist
Der Zufallsmultiplikator wird als *Full-Jitter* bezeichnet. Andernfalls würden alle Clients, bei denen gleichzeitig ein Fehler aufgetreten ist, es gleichzeitig erneut versuchen, was zu einem Anstieg von Wiederholungsverkehr führen würde (das Problem der „donnernden Herde“). Bei vollständigem Jitter werden die Wiederholungsversuche gleichmäßig über das gesamte Backoff-Fenster verteilt, sodass der Service statt synchronisierter Spitzenwerte ein regelmäßiges Rinnsal von Anfragen erhält.
Nehmen wir zum Beispiel an, 1.000 Clients erhalten alle gleichzeitig einen 503. Bei vollständigem Jitter werden die ersten Versuche gleichmäßig über ein 50-ms-Fenster verteilt, anstatt dass alle 1.000 Wiederholungen genau 50 ms dauern.
#### Server-directed Timing der Wiederholungsversuche
Einige AWS-Services enthalten einen `x-amz-retry-after` Header in 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 der berechnete Backoff selbst auf 20 Sekunden begrenzt ist, beträgt die effektive maximale servergesteuerte Verzögerung 25 Sekunden. Das SDK wendet auf diesen Wert keinen Jitter an, da vom Dienst erwartet wird, dass er jitter wird. Auf diese Weise kann der Dienst genau dann kommunizieren, wenn er erwartet, dass Kapazität verfügbar ist.
### Kontingent erneut versuchen (Token-Bucket)
Das SDK verwaltet ein internes Token-Budget, das das Verhältnis von erfolgreichen Anfragen zu Fehlschlägen verfolgt. Wenn Fehler weit verbreitet sind, wird das Budget aufgebraucht und das SDK gibt Fehler direkt zurück. Ihre Anwendung schlägt schnell fehl, anstatt Wiederholungsversuche abzuwarten, deren Erfolg unwahrscheinlich ist. Dadurch wird auch der Datenverkehr mit Wiederholungsversuchen reduziert, sodass Serviceunterbrechungen schneller behoben werden können.
#### So funktioniert das Wiederholungskontingent
Das Token-Budget ist am Anfang 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 erneuten Versuche erforderlich), stellt das SDK 1 Token wieder her. Wenn das Budget Null erreicht, hört das SDK auf, es erneut zu versuchen, und gibt Fehler direkt an Ihren Code zurück.
| Parameter | Wert |
| --- | --- |
| Kapazität des Budgets | 500 Wertmarken |
| Kosten pro vorübergehendem (ohne Drosselung) Wiederholungsversuch | 14 Tokens |
| Kosten pro Drosselungswiederholung | 5 Wertmarken |
| Tokens wurden bei Erfolg nach einem erneuten Versuch wiederhergestellt | Beim letzten Versuch verbrauchte Menge (14 oder 5) |
| Tokens wurden bei Erfolg ohne erneuten Versuch wiederhergestellt | 1 Token |
Die höheren Kosten für vorübergehende Wiederholungen sind auf das unterschiedliche Fehlermuster zurückzuführen. Vorübergehende Fehler wie 500er Fehler und Verbindungsausfälle deuten häufig auf ein dienstweites Problem hin. In diesen Situationen ist es unwahrscheinlich, dass ein erneuter Versuch erfolgreich ist. Dies erhöht die Latenz Ihrer Anrufe, bindet Client-Ressourcen und kann die Wiederherstellung für alle verzögern. Drosselungsfehler signalisieren, dass der Dienst mehr Zeit benötigt, bis die Anfrage erfolgreich ausgeführt werden kann. Das SDK wartet zwischen den Wiederholungen länger, um die Erfolgswahrscheinlichkeit zu erhöhen.
#### Wann blockiert das Kontingent Wiederholungsversuche
Das Wiederholungskontingent verfolgt Tokens jederzeit, blockiert aber 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 erneuten Versuch 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 Versuch fehlschlägt und der zweite erfolgreich ist, verliert das Budget netto 14 Token. Das Budget wird am schnellsten aufgebraucht, wenn bei Wiederholungsversuchen alle Versuche erschöpft sind, aber es wird auch allmählich aufgebraucht, wenn Anfragen mehrere Wiederholungen erfordern, bevor sie erfolgreich sind.
**Bei der Standardeinstellung von maximal 3 Versuchen beginnt das Kontingent zu sinken, wenn mehr als etwa **22%** der Anfragen zu dauerhaften vorübergehenden Ausfällen führen, oder mehr als etwa 32% bei Drosselungsfehlern.** Unterhalb dieser Raten wird das Budget durch erfolgreiche Anfragen schneller aufgefüllt, als durch fehlgeschlagene Wiederholungen aufgebraucht wird.
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 Wiederholungsversuche nicht, es sei denn, er dauert lange genug an, um den Puffer zu leeren.
#### Praktische Implikationen
+ **Niedrige Ausfallraten:** Die Quote hat keine Wirkung. Das Budget bleibt auf oder nahe der Kapazitätsgrenze.
+ **Während einer Serviceunterbrechung:** Wenn ein hoher Prozentsatz Ihrer Anfragen über einen längeren Zeitraum fehlschlägt, wird das Kontingent aufgebraucht und Ihr Kunde erhält sofort Fehler zurück, anstatt Wiederholungen abzuwarten. Dadurch wird die Latenz auf der Clientseite reduziert, Threads und Verbindungen freigegeben und der Service kann schneller wiederhergestellt werden.
+ **Wiederherstellung: Wenn** der Dienst wiederhergestellt wird und die Anfragen wieder erfolgreich sind, werden bei erfolgreichen Wiederholungsversuchen die vollen Token-Kosten wiederhergestellt, und bei Erfolgen beim ersten Versuch wird 1 Token wiederhergestellt. Das Budget wird schrittweise aufgefüllt und die Wiederholungsversuche werden automatisch fortgesetzt.
+ **Umfang:** Das Token-Budget ist in der Regel auf eine einzelne SDK-Clientinstanz beschränkt. Der genaue Umfang kann je nach SDK variieren. Er wird nicht von Prozessen oder Hosts gemeinsam genutzt.
### Service-specific Verhalten
#### DynamoDB
DynamoDB-Clients verwenden abgestimmte Standardeinstellungen, die für das Profil mit niedriger Latenz von DynamoDB optimiert sind:
| Einstellung | Allgemeine Standardeinstellung | DynamoDB-Standard |
| --- | --- | --- |
| Vorübergehende Basisverzögerung (ohne Drosselung) | 50 ms | 25 ms |
| Basisverzögerung bei Drosselung | 1.000 ms | 1.000 ms |
| Max. Versuche | 3 | 4 |
Diese Standardeinstellungen gelten sowohl für Amazon DynamoDB als auch für DynamoDB Streams.
#### Long-polling Operationen
Bei bestimmten AWS Vorgängen werden lange Abfragen verwendet. Sie können eine Verbindung offen halten und darauf warten, dass Arbeit eintrifft. Für diese Operationen gilt eine spezielle Wiederholungsbehandlung:
+ `SQS.ReceiveMessage`
+ `SFN.GetActivityTask`
+ `SWF.PollForActivityTask`
+ `SWF.PollForDecisionTask`
**Spezielles Verhalten:** Wenn das Wiederholungskontingent erschöpft ist und Wiederholungsversuche blockiert werden (Schritt 7 in[Was passiert, wenn eine Anfrage fehlschlägt](#what-happens-when-a-request-fails)), wendet das SDK immer noch eine Backoff-Verzögerung an, bevor der Fehler an Ihren Code zurückgegeben wird.
Dies ist wichtig, da lange Abfragevorgänge normalerweise in einer engen Schleife aufgerufen werden. Ihr Code ruft auf`ReceiveMessage`, 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 ohne Verzögerung Fehler zurückgibt. Ihre Abfrageschleife 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. Durch die erzwungene Backoff-Verzögerung wird dieser Zyklus unterbrochen, sodass die Nutzung der Client-Ressourcen und die Abfragerate bei Ausfällen überschaubar bleiben.
## Support durch AWS SDKs und Tools
In der folgenden Tabelle ist die Verfügbarkeit des aktualisierten Wiederholungsverhaltens in den einzelnen SDKs aufgeführt. SDK-specific Einzelheiten, einschließlich der Mindestversion, der Standardwerte vor und nach der Aktualisierung und Codebeispiele, finden Sie unter dem Thema Nachverfolgung. GitHub
| SDK | Unterstützt | GitHub Problem mit der Nachverfolgung |
| --- | --- | --- |
| [SDK for Java 2.x](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/) | Ja | [Problem mit der Nachverfolgung](https://github.com/aws/aws-sdk-java-v2/discussions/6984) |
| [SDK for Python (Boto3)](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html) | Ja | [Problem bei der Nachverfolgung](https://github.com/boto/boto3/discussions/4789) |
| [SDK for .NET 4.x](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/) | Ja | [Problem mit der Nachverfolgung](https://github.com/aws/aws-sdk-net/issues/4411) |
| [Tools für PowerShell V5](https://docs.aws.amazon.com/powershell/latest/userguide/) | Ja | [Problem mit der Nachverfolgung](https://github.com/aws/aws-tools-for-powershell/issues/418) |
| [SDK für JavaScript 3.x](https://docs.aws.amazon.com/sdk-for-javascript/latest/developer-guide/) | Ja | [Problem mit der Nachverfolgung](https://github.com/aws/aws-sdk-js-v3/issues/8037) |
| [SDK for PHP 3.x](https://docs.aws.amazon.com/sdk-for-php/latest/developer-guide/) | Ja | [Problem mit der Nachverfolgung](https://github.com/aws/aws-sdk-php/discussions/3285) |
| [SDK für Kotlin](https://docs.aws.amazon.com/sdk-for-kotlin/latest/developer-guide/) | Ja | [Problem mit der Nachverfolgung](https://github.com/aws/aws-sdk-kotlin/discussions/1885) |
| [SDK für Rust](https://docs.aws.amazon.com/sdk-for-rust/latest/dg/) | Ja | [Problem mit der Nachverfolgung](https://github.com/awslabs/aws-sdk-rust/discussions/1431) |
| [SDK für Swift](https://docs.aws.amazon.com/sdk-for-swift/latest/developer-guide/) | Siehe Problem mit der Nachverfolgung | [Problem mit der Nachverfolgung](https://github.com/awslabs/aws-sdk-swift/discussions/2166) |
| [SDK for Ruby 3.x](https://docs.aws.amazon.com/sdk-for-ruby/latest/developer-guide/) | Siehe Problem mit der Nachverfolgung | [Problem mit der Nachverfolgung](https://github.com/aws/aws-sdk-ruby/discussions/3390) |
| [SDK for Go V2 (1.x)](https://docs.aws.amazon.com/sdk-for-go/v2/developer-guide/) | Siehe Problem mit der Nachverfolgung | [Problem mit der Nachverfolgung](https://github.com/aws/aws-sdk-go-v2/issues/3416) |
| [SDK for C\+\+](https://docs.aws.amazon.com/sdk-for-cpp/latest/developer-guide/) | Siehe Problem mit der Nachverfolgung | [Problem mit der Nachverfolgung](https://github.com/aws/aws-sdk-cpp/issues/3832) |
| [AWS CLI ](https://docs.aws.amazon.com/cli/latest/userguide/) v2 | Siehe Problem mit der Nachverfolgung | [Problem mit der Nachverfolgung](https://github.com/aws/aws-cli/discussions/10329) |