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
Das Wiederholungsverhalten umfasst Einstellungen, die festlegen, wie die SDKs versuchen, nach Fehlern aufgrund von Anfragen an eine Wiederherstellung zu versuchen. AWS-Services
Konfigurieren Sie diese Funktionalität wie folgt:
max_attempts
- Einstellung für gemeinsam genutzte AWSconfig
DateienAWS_MAX_ATTEMPTS
- Umgebungsvariableaws.maxAttempts
- JVM-Systemeigenschaft: Nur Java/Kotlin-
Gibt die maximale Anzahl an Versuchen an, die bei einer Anfrage unternommen werden können.
Standardwert: Wenn dieser Wert nicht angegeben ist, hängt sein Standardwert vom Wert der
retry_mode
Einstellung ab:-
Falls
retry_mode
jalegacy
— Verwendet einen für Ihr SDK spezifischen Standardwert (denmax_attempts
Standardwert finden Sie in Ihrem spezifischen SDK-Handbuch oder in der Codebasis Ihres SDK). -
Falls
retry_mode
jastandard
— Unternimmt drei Versuche. -
Falls
retry_mode
jaadaptive
— Führt drei Versuche durch.
Gültige Werte: Zahl größer als 0.
-
retry_mode
- Einstellung für gemeinsam genutzte AWSconfig
DateienAWS_RETRY_MODE
- Umgebungsvariableaws.retryMode
- JVM-Systemeigenschaft: Nur Java/Kotlin-
Gibt an, wie das SDK oder das Entwicklertool versucht, es erneut zu versuchen.
Standardwert:
legacy
ist die Standardstrategie für Wiederholungsversuche.Zulässige Werte:
-
legacy
— Spezifisch für Ihr SDK (lesen Sie in Ihrem spezifischen SDK-Handbuch oder in der Codebasis Ihres SDK nach). -
standard
— Der Standardsatz von Wiederholungsregeln für alle AWS SDKs. Dieser Modus umfasst einen Standardsatz von Fehlern, die wiederholt werden, und Unterstützung für Wiederholungsquoten. Die standardmäßige maximale Anzahl von Versuchen in diesem Modus beträgt drei, sofern nicht ausdrücklichmax_attempts
konfiguriert. -
adaptive
— Ein experimenteller Wiederholungsmodus, der die Funktionalität des Standardmodus beinhaltet, aber auch automatische clientseitige Drosselung beinhaltet. Da es sich bei diesem Modus um einen experimentellen Modus handelt, könnte er das Verhalten in future ändern.
-
Wählen Sie zwischen den Modi standard
und adaptive
versuchen Sie es erneut
Wir empfehlen Ihnen, den standard
Wiederholungsmodus zu verwenden, es sei denn, Sie sind sich sicher, dass Ihre Verwendung dafür besser geeignet ist. adaptive
Anmerkung
In diesem adaptive
Modus wird davon ausgegangen, dass Sie Clients auf der Grundlage des Bereichs, in dem der Back-End-Dienst Anfragen drosseln kann, zusammenfassen. Wenn Sie dies nicht tun, können Drosselungen in einer Ressource Anfragen für eine Ressource verzögern, wenn Sie denselben Client für beide Ressourcen verwenden.
Standard | Adaptiv |
---|---|
Anwendungsfälle: Alle. | Anwendungsfälle für Anwendungen:
|
Unterstützt Circuit-Breaking, um zu verhindern, dass das SDK es bei Ausfällen erneut versucht. | Unterstützt Circuit-Breaking, um zu verhindern, dass das SDK es bei Ausfällen erneut versucht. |
Verwendet bei Ausfällen einen exponentiellen Jitter-Backoff. | Verwendet dynamische Backoff-Dauern, um zu versuchen, die Anzahl der fehlgeschlagenen Anfragen zu minimieren, als Gegenleistung für die mögliche Erhöhung der Latenz. |
Verzögert niemals den ersten Anforderungsversuch, sondern nur die Wiederholungsversuche. | Kann den ersten Anforderungsversuch drosseln oder verzögern. |
Wenn Sie den adaptive
Modus verwenden möchten, muss Ihre Anwendung Clients erstellen, die für jede Ressource konzipiert sind, die möglicherweise gedrosselt wird. Eine Ressource ist in diesem Fall besser abgestimmt, als nur an jede einzelne Ressource zu denken. AWS-Service AWS-Services kann zusätzliche Dimensionen haben, die sie verwenden, um Anfragen zu drosseln. Lassen Sie uns den Amazon DynamoDB-Service als Beispiel verwenden. DynamoDB verwendet AWS-Region plus die Tabelle, auf die zugegriffen wird, um Anfragen zu drosseln. Das bedeutet, dass eine Tabelle, auf die Ihr Code zugreift, möglicherweise stärker gedrosselt wird als andere. Wenn Ihr Code denselben Client für den Zugriff auf alle Tabellen verwendet hat und Anfragen an eine dieser Tabellen gedrosselt werden, reduziert der adaptive Wiederholungsmodus die Anforderungsrate für alle Tabellen. Ihr Code sollte so konzipiert sein, dass er einen Client pro egion-and-table R-Paar hat. Wenn Sie bei der Verwendung des adaptive
Modus eine unerwartete Latenz feststellen, lesen Sie in der spezifischen AWS Dokumentation des von Ihnen verwendeten Dienstes nach.
Einzelheiten zur Implementierung des Wiederholungsmodus
Im Folgenden finden Sie den allgemeinen Pseudocode für den Modus standard
und adaptive
den Wiederholungsmodus:
MakeSDKRequest() { attempts = 0 loop { GetSendToken() response = SendHTTPRequest() RequestBookkeeping(response) if not Retryable(response) return response attempts += 1 if attempts >= MAX_ATTEMPTS: return response if not HasRetryQuota(response) return response delay = ExponentialBackoff(attempts) sleep(delay) } }
Im Folgenden finden Sie weitere Informationen zu den im Pseudocode verwendeten Komponenten:
GetSendToken
:
Token-Buckets werden nur im adaptive
Wiederholungsmodus verwendet. Token-Buckets setzen eine maximale Anforderungsrate durch, indem sie verlangen, dass ein Token verfügbar ist, um eine Anfrage zu initiieren. Der SDK-Client kann so konfiguriert werden, dass die Anfrage entweder schnell fehlschlägt oder blockiert wird, bis ein Token verfügbar ist.
Bei der clientseitigen Ratenbegrenzung handelt es sich um einen Algorithmus, mit dem Anfragen zunächst in beliebiger Geschwindigkeit gestellt werden können, bis die Token-Zulage erreicht ist. Sobald jedoch eine gedrosselte Antwort erkannt wird, wird der Client rate-of-request entsprechend eingeschränkt. Die Token-Zulage wird ebenfalls entsprechend erhöht, wenn erfolgreiche Antworten eingehen.
Mit adaptiver Ratenbegrenzung können SDKs die Geschwindigkeit, mit der Anfragen gesendet werden, verlangsamen, um der Kapazität von AWS-Services besser gerecht zu werden.
SendHTTPRequest
:
Die meisten AWS SDKs verwenden eine HTTP-Bibliothek, die Verbindungspools verwendet, sodass Sie eine bestehende Verbindung wiederverwenden können, wenn Sie eine HTTP-Anfrage stellen. Im Allgemeinen werden Verbindungen aufgrund von Drosselungsfehlern wiederverwendet, wenn Anfragen erneut versucht werden. Anfragen werden bei Wiederholungsversuchen aufgrund vorübergehender Fehler nicht wiederverwendet.
RequestBookkeeping
:
Das Wiederholungskontingent sollte aktualisiert werden, wenn die Anfrage erfolgreich ist. Nur im adaptive
Wiederholungsmodus maxsendrate
wird die Statusvariable basierend auf der Art der empfangenen Antwort aktualisiert.
Retryable
:
In diesem Schritt wird anhand der folgenden Kriterien bestimmt, ob eine Antwort erneut versucht werden kann:
-
Den HTTP-Statuscode .
-
Der vom Dienst zurückgegebene Fehlercode.
-
Verbindungsfehler, definiert als jeder vom SDK empfangene Fehler, bei dem keine HTTP-Antwort vom Dienst empfangen wird.
Vorübergehende Fehler (HTTP-Statuscodes 400, 408, 500, 502, 503 und 504) und Drosselungsfehler (HTTP-Statuscodes 400, 403, 429, 502, 503 und 509) können alle potenziell wiederholt werden. Das SDK-Wiederholungsverhalten wird in Kombination mit Fehlercodes oder anderen Daten aus dem Dienst bestimmt.
MAX_ATTEMPTS
:
Wird durch die config
Dateieinstellung oder die Umgebungsvariable angegeben.
HasRetryQuota
In diesem Schritt werden Wiederholungsanforderungen eingeschränkt, da ein Token im Quotenbereich für Wiederholungsversuche verfügbar sein muss. Kontingentgruppen für Wiederholungsversuche sind ein Mechanismus, um Wiederholungsversuche zu verhindern, deren Erfolg unwahrscheinlich ist. Diese Kontingente hängen vom SDK, oft vom Client und manchmal sogar von den Dienstendpunkten ab. Die verfügbaren Quota-Token für Wiederholungsversuche werden entfernt, wenn Anfragen aus verschiedenen Gründen fehlschlagen, und wieder aufgefüllt, wenn sie erfolgreich sind. Wenn keine Token mehr vorhanden sind, wird die Wiederholungsschleife beendet.
ExponentialBackoff
Bei einem Fehler, der wiederholt werden kann, wird die Wiederholungsverzögerung anhand eines verkürzten exponentiellen Backoffs berechnet. Die SDKs verwenden abgeschnittenes binäres exponentielles Backoff mit Jitter. Der folgende Algorithmus zeigt, wie die Zeit bis zum Ruhezustand (in Sekunden) für eine Antwort auf Anfrage definiert wird: i
seconds_to_sleep_i = min(b*r^i, MAX_BACKOFF)
Im vorherigen Algorithmus gelten die folgenden Werte:
b = random number within the range of: 0 <= b <= 1
r = 2
MAX_BACKOFF = 20 seconds
für die meisten SDKs. Weitere Informationen finden Sie in Ihrem spezifischen SDK-Leitfaden oder Quellcode.
Kompatibilität mit AWS SDKs
Die folgenden SDKs unterstützen die in diesem Thema beschriebenen Funktionen und Einstellungen. Alle teilweisen Ausnahmen werden vermerkt. Alle Einstellungen für JVM-Systemeigenschaften werden AWS SDK for Kotlin nur von AWS SDK for Java und vom unterstützt.
SDK | Unterstützt | Hinweise oder weitere Informationen |
---|---|---|
AWS CLI v2 | Ja | |
SDK for C++ | Ja | |
SDK for Go V2 (1.x) |
Ja | |
SDK for Go 1.x (V1) | Nein | |
SDK for Java 2.x | Ja | |
SDK for Java 1.x | Ja | JVM-Systemeigenschaften: anstelle von verwendenaws.maxAttempts ; com.amazonaws.sdk.maxAttempts anstelle von verwendencom.amazonaws.sdk.retryMode . aws.retryMode |
SDK für 3.x JavaScript | Ja | |
SDK für 2.x JavaScript | Nein | Unterstützt eine maximale Anzahl von Wiederholungsversuchen, exponentielles Backoff mit Jitter und eine Option für eine benutzerdefinierte Methode für Wiederholungs-Backoff. |
SDK für Kotlin | Ja | |
SDK for .NET 3.x | Ja | |
SDK for PHP 3.x | Ja | |
SDK for Python (Boto3) |
Ja | |
SDK for Ruby 3.x | Ja | |
SDK für Rust | Ja | |
Tools für PowerShell | Ja |