Wiederholungsverhalten - AWS SDKs und Tools

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 AWS config Dateien
AWS_MAX_ATTEMPTS- Umgebungsvariable
aws.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 ja legacy — Verwendet einen für Ihr SDK spezifischen Standardwert (den max_attempts Standardwert finden Sie in Ihrem spezifischen SDK-Handbuch oder in der Codebasis Ihres SDK).

  • Falls retry_mode ja standard — Unternimmt drei Versuche.

  • Falls retry_mode ja adaptive — Führt drei Versuche durch.

Gültige Werte: Zahl größer als 0.

retry_mode- Einstellung für gemeinsam genutzte AWS config Dateien
AWS_RETRY_MODE- Umgebungsvariable
aws.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ücklich max_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:
  1. Unempfindlich gegenüber Latenz.

  2. Der Client greift nur auf eine einzelne Ressource zu, oder Sie stellen Logik bereit, um Ihre Clients getrennt nach der Dienstressource, auf die zugegriffen wird, in einem Pool zusammenzufassen.

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 secondsfü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