Auf dieser Seite wird beschrieben, wie Cloud Storage-Tools fehlgeschlagene Anfragen wiederholen und wie Sie das Verhalten von Wiederholungsversuchen anpassen. Außerdem werden Überlegungen zur Wiederholung von Anfragen beschrieben.
Übersicht
Es gibt zwei Faktoren, die bestimmen, ob eine Anfrage sicher wiederholt werden kann:
Die Antwort, die Sie von der Anfrage erhalten.
Die Idempotenz der Anfrage.
Antwort
Die Antwort, die Sie von Ihrer Anfrage erhalten, gibt an, ob es sinnvoll ist, die Anfrage zu wiederholen. Antworten auf vorübergehende Probleme sind in der Regel wiederholbar. Andererseits zeigen Antworten auf permanente Fehler, dass Sie Änderungen wie Autorisierungs- oder Konfigurationsänderungen vornehmen müssen, bevor es sinnvoll ist, die Anfrage noch einmal zu senden. Die folgenden Antworten weisen auf vorübergehende Probleme hin, die wiederholt werden können:
- HTTP-Antwortcodes
408
,429
und5xx
. - Socket-Zeitüberschreitungen und getrennte TCP-Verbindungen
Weitere Informationen finden Sie in den Status- und Fehlercodes für JSON und XML-Code.
Idempotenz
Idempotente Anfragen können wiederholt ausgeführt werden, ohne den Endzustand der Zielressource zu ändern. Das Ergebnis ist jedes Mal derselbe Endzustand. Zum Beispiel sind Auflistungsvorgänge immer idempotent, weil solche Anfragen keine Ressourcen ändern. Andererseits ist das Erstellen einer neuen Pub/Sub-Benachrichtigung niemals idempotent, da bei jeder erfolgreichen Anfrage eine neue Benachrichtigungs-ID erstellt wird.
Die folgenden Beispiele zeigen Bedingungen, die einen Vorgang idempotent machen:
Der Vorgang hat auch dann sichtbare Auswirkungen auf die Zielressource, wenn er kontinuierlich angefragt wird.
Der Vorgang ist nur einmal erfolgreich.
Der Vorgang hat keine sichtbaren Auswirkungen auf den Status der Zielressource.
Wenn Sie eine wiederholbare Antwort erhalten, sollten Sie die Idempotenz der Anfrage berücksichtigen, da Wiederholungsanfragen, die nicht idempotent sind, zu Race-Bedingungen und anderen Konflikten führen können.
Bedingte Idempotenz
Teilmengen von Anfragen sind bedingt idempotent. Das bedeutet, dass sie nur idempotent sind, wenn sie bestimmte optionale Argumente enthalten. Vorgänge, für die ein bedingter Versuch wiederholt werden muss, sollten nur dann wiederholt werden, wenn der Bedingungsfall erfolgreich ist. Cloud Storage akzeptiert Vorbedingungen und ETags als Bedingungsfälle für Anfragen.
Idempotenz von Vorgängen
In der folgenden Tabelle sind die Cloud Storage-Vorgänge aufgeführt, die unter die einzelnen Kategorien der Idempotenz fallen.
Idempotenz | Operations |
---|---|
Immer idempotent |
|
Bedingt idempotent |
|
Nie idempotent |
|
1Dieses Feld kann in der JSON API verwendet werden. Informationen zu Feldern, die in den Clientbibliotheken verwendet werden können, finden Sie in der entsprechenden Dokumentation zur Clientbibliothek.
Wie Cloud Storage-Tools Wiederholungsstrategien implementieren
Console
Die Google Cloud Console sendet in Ihrem Namen Anfragen an Cloud Storage und sorgt für die Bearbeitung aller erforderlichen Backoffs.
Befehlszeile
gcloud storage
-Befehle wiederholen die Fehler, die im Abschnitt Antwort aufgeführt sind, ohne dass Sie zusätzliche Maßnahmen ergreifen müssen.
Bei folgenden Fehlern müssen Sie unter Umständen Maßnahmen ergreifen:
Ungültige Anmeldedaten oder unzureichende Berechtigungen.
Das Netzwerk ist nicht erreichbar, da Probleme mit der Proxykonfiguration aufgetreten sind.
Bei wiederholbaren Fehlern wiederholt die gcloud CLI Anfragen nach der Strategie eines abgeschnittenen binären exponentiellen Backoffs: Die Standardanzahl maximaler Wiederholungsversuche beträgt 32 für die gcloud CLI.
Clientbibliotheken
C++
Standardmäßig unterstützen die Vorgänge Wiederholungsversuche für die folgenden HTTP-Fehlercodes sowie für alle Socket-Fehler, die darauf hinweisen, dass die Verbindung verloren gegangen ist oder nie erfolgreich hergestellt wurde.
408 Request Timeout
429 Too Many Requests
500 Internal Server Error
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
Alle Einstellungen für exponentielle Backoffs und Wiederholungsversuche in der C++-Bibliothek sind konfigurierbar. Wenn die in der Bibliothek implementierten Algorithmen Ihre Anforderungen nicht unterstützen, können Sie benutzerdefinierten Code bereitstellen, um Ihre eigenen Strategien zu implementieren.
Einstellung | Standardwert |
---|---|
Automatische Wiederholung | Wahr |
Maximale Dauer, die eine Anfrage wiederholt wird | 15 Minuten |
Erste Wartezeit (Backoff) | 1 Sekunde |
Multiplikator für die Wartezeit pro Ausführung | 2 |
Maximale Wartezeit | 5 Minuten |
Standardmäßig wiederholt die C++-Bibliothek alle Operationen mit wiederholbaren Fehlern, auch solche, die nie idempotent sind und bei erfolgreicher Wiederholung mehrere Ressourcen löschen oder erstellen können. Wenn Sie nur idempotente Vorgänge wiederholen möchten, verwenden Sie die google::cloud::storage::StrictIdempotencyPolicy
-Klasse.
C#
In der C#-Clientbibliothek wird exponentieller Backoff standardmäßig verwendet.
Go
Standardmäßig unterstützen Vorgänge Wiederholungsversuche für die folgenden Fehler:
- Verbindungsfehler:
io.ErrUnexpectedEOF
: Dies kann aufgrund vorübergehender Netzwerkprobleme auftreten.url.Error
mitconnection refused
: Dies kann aufgrund vorübergehender Netzwerkprobleme auftreten.url.Error
mitconnection reset by peer
: Dies bedeutet, dass Google Cloud die Verbindung zurückgesetzt hat.net.ErrClosed
: Dies bedeutet, dass Google Cloud die Verbindung geschlossen hat.
- HTTP-Codes:
408 Request Timeout
429 Too Many Requests
500 Internal Server Error
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
- Fehler, die die Schnittstelle
Temporary()
implementieren und den Werterr.Temporary() == true
angeben - Alle oben genannten Fehler, die mit Go 1.13-Fehlerverpackung verpackt wurden
Alle Einstellungen für exponentielle Backoffs in der Go-Bibliothek können konfiguriert werden. Standardmäßig verwenden Vorgänge in Go die folgenden Einstellungen für den exponentiellen Backoff (Standardeinstellungen werden von gax übernommen):
Einstellung | Standardwert (in Sekunden) |
---|---|
Automatische Wiederholung | Wahr, wenn idempotent |
Maximale Anzahl an Versuchen | Kein Limit |
Verzögerung für erste Wiederholung: | 1 Sekunde |
Multiplikator für die Verzögerung der Wiederholung | 2,0 |
Maximale Wiederholungsverzögerung | 30 Sekunden |
Gesamtzeitüberschreitung (fortsetzbarer Uploadblock) | 32 Sekunden |
Gesamtzeitüberschreitung (alle anderen Vorgänge) | Kein Limit |
Der Wiederholungsversuch wird in der Regel unbegrenzt fortgesetzt, es sei denn, der Steuerungskontext wird abgebrochen, der Client wird geschlossen oder ein nicht vorübergehender Fehler wird empfangen. Verwenden Sie Kontextzeitüberschreitungen oder einen Abbruch, um zu verhindern, dass Wiederholungsversuche fortgesetzt werden. Die einzige Ausnahme bei diesem Verhalten ist, wenn fortsetzbare Uploads mit Writer durchgeführt werden, wobei die Daten groß genug sind, dass mehrere Anfragen erforderlich sind. In diesem Szenario tritt bei jedem Block eine Zeitüberschreitung auf und beendet die Wiederholung standardmäßig nach 32 Sekunden. Sie können das Standardzeitlimit anpassen, indem Sie Writer.ChunkRetryDeadline
ändern.
Es gibt eine Teilmenge von Go-Vorgängen, die bedingt idempotent sind (bedingt sicher bei erneuter Wiederholung). Diese Vorgänge werden nur dann wiederholt, wenn sie bestimmte Bedingungen erfüllen:
GenerationMatch
oderGeneration
- Wiederholen Sie den Vorgang, wenn die Vorbedingung
GenerationMatch
auf den Aufruf angewendet wurde oder wennObjectHandle.Generation
festgelegt wurde.
- Wiederholen Sie den Vorgang, wenn die Vorbedingung
MetagenerationMatch
- Wiederholen Sie den Vorgang, wenn die Vorbedingung
MetagenerationMatch
auf den Aufruf angewendet wurde.
- Wiederholen Sie den Vorgang, wenn die Vorbedingung
Etag
- Es kann wiederholt werden, wenn die Methode
etag
in den JSON-Anfragetext einfügt. Wird nur inHMACKeyHandle.Update
verwendet, wennHmacKeyMetadata.Etag
festgelegt wurde.
- Es kann wiederholt werden, wenn die Methode
RetryPolicy
ist standardmäßig auf RetryPolicy.RetryIdempotent
festgelegt. Unter Wiederholungen anpassen finden Sie Beispiele zum Ändern des Standardverhaltens bei Wiederholungsversuchen.
Java
Standardmäßig unterstützen Vorgänge Wiederholungsversuche für die folgenden Fehler:
- Verbindungsfehler:
Connection reset by peer
: Dies bedeutet, dass Google Cloud die Verbindung zurückgesetzt hat.Unexpected connection closure
: Dies bedeutet, dass Google Cloud die Verbindung geschlossen hat.
- HTTP-Codes:
408 Request Timeout
429 Too Many Requests
500 Internal Server Error
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
Alle Einstellungen für exponentielle Backoffs in der Java-Bibliothek können konfiguriert werden. Standardmäßig verwenden Vorgänge über Java für den exponentiellen Backoff die folgenden Einstellungen:
Einstellung | Standardwert (in Sekunden) |
---|---|
Automatische Wiederholung | Wahr, wenn idempotent |
Maximale Anzahl an Versuchen | 6 |
Verzögerung für erste Wiederholung: | 1 Sekunde |
Multiplikator für die Verzögerung der Wiederholung | 2,0 |
Maximale Wiederholungsverzögerung | 32 Sekunden |
Zeitüberschreitung insgesamt | 50 Sekunden |
Anfängliche RPC-Zeitüberschreitung | 50 Sekunden |
RPC-Zeitüberschreitungsmultiplikator | 1,0 |
Maximales RPC-Zeitlimit | 50 Sekunden |
Zeitüberschreitung beim Verbindungsaufbau | 20 Sekunden |
Lesezeitüberschreitung | 20 Sekunden |
Weitere Informationen zu den Einstellungen finden Sie in der Java-Referenzdokumentation für RetrySettings.Builder
und HttpTransportOptions.Builder
.
Es gibt eine Teilmenge von Java-Vorgängen, die bedingt idempotent sind (bedingt sicher bei erneutem Versuch). Diese Vorgänge werden nur dann wiederholt, wenn sie bestimmte Argumente enthalten:
ifGenerationMatch
odergeneration
- Sicher für Wiederholung, wenn
ifGenerationMatch
odergeneration
als Option an die Methode übergeben wurde.
- Sicher für Wiederholung, wenn
ifMetagenerationMatch
- Wiederholen Sie den Vorgang, wenn
ifMetagenerationMatch
als Option übergeben wurde.
- Wiederholen Sie den Vorgang, wenn
StorageOptions.setStorageRetryStrategy
ist standardmäßig auf StorageRetryStrategy#getDefaultStorageRetryStrategy
festgelegt.
Unter Wiederholungen anpassen finden Sie Beispiele zum Ändern des Standardverhaltens bei Wiederholungsversuchen.
Node.js
Standardmäßig unterstützen Vorgänge Wiederholungsversuche für die folgenden Fehlercodes:
- Verbindungsfehler:
EAI_again
: Dies ist ein DNS-Lookup-Fehler. Weitere Informationen finden Sie in der Dokumentation zugetaddrinfo
.Connection reset by peer
: Dies bedeutet, dass Google Cloud die Verbindung zurückgesetzt hat.Unexpected connection closure
: Dies bedeutet, dass Google Cloud die Verbindung geschlossen hat.
- HTTP-Codes:
408 Request Timeout
429 Too Many Requests
500 Internal Server Error
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
Alle Einstellungen für exponentielle Backoffs in der Node.js-Bibliothek können konfiguriert werden. Standardmäßig verwenden Vorgänge über Node.js die folgenden Einstellungen für den exponentiellen Backoff:
Einstellung | Standardwert (in Sekunden) |
---|---|
Automatische Wiederholung | Wahr, wenn idempotent |
Maximale Anzahl an Wiederholungen | 3 |
Anfängliche Wartezeit | 1 Sekunde |
Multiplikator für die Wartezeit pro Ausführung | 2 |
Maximale Wartezeit | 64 Sekunden |
Standardfrist | 600 Sekunden |
Es gibt eine Teilmenge von Node.js-Vorgängen, die bedingt idempotent sind und unter bestimmten Bedingungen wiederholt werden können. Diese Vorgänge werden nur dann wiederholt, wenn sie bestimmte Argumente enthalten:
ifGenerationMatch
odergeneration
- Sicher für Wiederholung, wenn
ifGenerationMatch
odergeneration
als Option an die Methode übergeben wurde. Häufig akzeptieren Methoden nur einen dieser beiden Parameter.
- Sicher für Wiederholung, wenn
ifMetagenerationMatch
- Wiederholen Sie den Vorgang, wenn
ifMetagenerationMatch
als Option übergeben wurde.
- Wiederholen Sie den Vorgang, wenn
retryOptions.idempotencyStrategy
ist standardmäßig auf IdempotencyStrategy.RetryConditional
festgelegt. Unter Wiederholungen anpassen finden Sie Beispiele zum Ändern des Standardverhaltens bei Wiederholungsversuchen.
PHP
In der PHP-Clientbibliothek wird exponentieller Backoff standardmäßig verwendet.
Python
Standardmäßig unterstützen Vorgänge Wiederholungsversuche für die folgenden Fehlercodes:
- Verbindungsfehler:
requests.exceptions.ConnectionError
requests.exceptions.ChunkedEncodingError
(nur für Vorgänge, die Nutzlastdaten abrufen oder an Objekte senden, z. B. Uploads und Downloads)ConnectionError
http.client.ResponseNotReady
urllib3.exceptions.TimeoutError
- HTTP-Codes:
408 Request Timeout
429 Too Many Requests
500 Internal Server Error
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
Für Vorgänge über Python werden die folgenden Standardeinstellungen für exponentielle Backoffs verwendet:
Einstellung | Standardwert (in Sekunden) |
---|---|
Automatische Wiederholung | Wahr, wenn idempotent |
Anfängliche Wartezeit | 1 |
Multiplikator für die Wartezeit pro Ausführung | 2 |
Maximale Wartezeit | 60 |
Standardfrist | 120 |
Zusätzlich zu Cloud Storage-Vorgängen, die immer idempotent sind, werden die Vorgänge Objects: insert, Objects: delete und Objects: patch in der Python-Clientbibliothek standardmäßig automatisch wiederholt.
Es gibt eine Teilmenge von Python-Vorgängen, die bedingt idempotent sind und unter bestimmten Bedingungen wiederholt werden können, wenn sie bestimmte Argumente enthalten. Diese Vorgänge werden nur dann wiederholt, wenn ein Bedingungsfall erfolgreich ist:
DEFAULT_RETRY_IF_GENERATION_SPECIFIED
- Sicher für Wiederholung, wenn
generation
oderif_generation_match
als Argument an die Methode übergeben wurde. Häufig akzeptieren Methoden nur einen dieser beiden Parameter.
- Sicher für Wiederholung, wenn
DEFAULT_RETRY_IF_METAGENERATION_SPECIFIED
- Sicher für Wiederholung, wenn
if_metageneration_match
als Argument an die Methode übergeben wurde.
- Sicher für Wiederholung, wenn
DEFAULT_RETRY_IF_ETAG_IN_JSON
- Es kann wiederholt werden, wenn die Methode
etag
in den JSON-Anfragetext einfügt. FürHMACKeyMetadata.update()
bedeutet dies, dass das ETag für dasHMACKeyMetadata
-Objekt selbst festgelegt werden muss. Für dieset_iam_policy()
-Methode in anderen Klassen bedeutet dies, dass das ETag im Argument "policy" festgelegt werden muss, das an die Methode übergeben wird.
- Es kann wiederholt werden, wenn die Methode
Ruby
Standardmäßig unterstützen Vorgänge Wiederholungsversuche für die folgenden Fehlercodes:
- Verbindungsfehler:
SocketError
HTTPClient::TimeoutError
Errno::ECONNREFUSED
HTTPClient::KeepAliveDisconnected
- HTTP-Codes:
408 Request Timeout
429 Too Many Requests
5xx Server Error
Alle Einstellungen für exponentielle Backoffs in der Ruby-Clientbibliothek können konfiguriert werden. Standardmäßig verwenden Vorgänge über die Ruby-Clientbibliothek die folgenden Einstellungen für den exponentiellen Backoff:
Einstellung | Standardwert |
---|---|
Automatische Wiederholung | Wahr |
Maximale Anzahl an Wiederholungen | 3 |
Anfängliche Wartezeit | 1 Sekunde |
Multiplikator für die Wartezeit pro Ausführung | 2 |
Maximale Wartezeit | 60 Sekunden |
Standardfrist | 900 Sekunden |
Es gibt eine Teilmenge von Ruby-Vorgängen, die bedingt idempotent sind und unter bestimmten Bedingungen wiederholt werden können, wenn sie bestimmte Argumente enthalten:
if_generation_match
odergeneration
- Sicher für Wiederholung, wenn der Parameter
generation
oderif_generation_match
als Argument an die Methode übergeben wird. Häufig akzeptieren Methoden nur einen dieser beiden Parameter.
- Sicher für Wiederholung, wenn der Parameter
if_metageneration_match
- Wiederholen Sie den Vorgang, wenn der Parameter
if_metageneration_match
als Option übergeben wird.
- Wiederholen Sie den Vorgang, wenn der Parameter
Standardmäßig werden alle idempotenten Vorgänge wiederholt, bedingte idempotente Vorgänge nur dann, wenn der Bedingungsfall erfolgreich ist. Nicht-idempotente Vorgänge werden nicht wiederholt. Unter Wiederholungen anpassen finden Sie Beispiele zum Ändern des Standardverhaltens bei Wiederholungsversuchen.
REST APIs
Wenn Sie die JSON- oder XML API direkt aufrufen, sollten Sie mit dem exponentiellen Backoff Ihre eigene Wiederholungsstrategie implementieren.
Wiederholungsversuche anpassen
Console
Über die Google Cloud Console können Sie das Verhalten von Wiederholungsversuchen nicht anpassen.
Befehlszeile
Bei gcloud storage
-Befehlen können Sie die Wiederholungsstrategie steuern, indem Sie eine benannte Konfiguration erstellen und einige oder alle der folgenden Attribute festlegen:
Einstellung | Standardwert (in Sekunden) |
---|---|
base_retry_delay |
1 |
exponential_sleep_multiplier |
2 |
max_retries |
32 |
max_retry_delay |
32 |
Anschließend wenden Sie die definierte Konfiguration entweder einzeln pro Befehl mit dem projektweiten --configuration
-Flag oder für alle Google Cloud CLI-Befehle mit dem gcloud config set
-Befehl an.
Clientbibliotheken
C++
Zum Anpassen des Wiederholungsverhaltens geben Sie Werte für die folgenden Optionen an, wenn Sie das Objekt google::cloud::storage::Client
initialisieren:
google::cloud::storage::RetryPolicyOption
: Die Bibliothek bietet die Klassengoogle::cloud::storage::LimitedErrorCountRetryPolicy
undgoogle::cloud::storage::LimitedTimeRetryPolicy
. Sie können Ihre eigene Klasse angeben, die die Schnittstellegoogle::cloud::RetryPolicy
implementieren muss.google::cloud::storage::BackoffPolicyOption
: Die Bibliothek bietet die Klassegoogle::cloud::storage::ExponentialBackoffPolicy
. Sie können Ihre eigene Klasse angeben, die die Schnittstellegoogle::cloud::storage::BackoffPolicy
implementieren muss.google::cloud::storage::IdempotencyPolicyOption
: Die Bibliothek stellt die Klassengoogle::cloud::storage::StrictIdempotencyPolicy
undgoogle::cloud::storage::AlwaysRetryIdempotencyPolicy
bereit. Sie können Ihre eigene Klasse angeben, die die Schnittstellegoogle::cloud::storage::IdempotencyPolicy
implementieren muss.
Weitere Informationen finden Sie in der Referenzdokumentation zur C++-Clientbibliothek.
C#
Sie können die von der C#-Clientbibliothek verwendete Standard-Wiederholungsstrategie nicht anpassen.
Go
Wenn Sie einen Storage-Client initialisieren, wird eine Standardkonfiguration für Wiederholungsversuche festgelegt. Wenn die Optionen nicht überschrieben werden, werden sie in der Konfiguration auf die Standardwerte gesetzt. Nutzer können ein nicht standardmäßiges Wiederholungsverhalten für einen einzelnen Bibliotheksaufruf (mit BucketHandle.Retryer und ObjectHandle.Retryer) oder für alle Aufrufe konfigurieren, die von einem Client (mit Client.SetRetry) gemacht werden. Um das Wiederholungsverhalten zu ändern, übergeben Sie die relevanten RetryOptions an eine dieser Methoden.
Im folgenden Codebeispiel erfahren Sie, wie Sie das Wiederholungsverhalten anpassen.
Java
Beim Initialisieren von Storage
wird auch eine Instanz von RetrySettings
initialisiert. Wenn die Optionen nicht überschrieben werden, werden sie in RetrySettings
auf die Standardwerte gesetzt. Um das Standardverhalten für die automatische Wiederholung zu ändern, übergeben Sie die benutzerdefinierte StorageRetryStrategy
an die StorageOptions
, die zum Erstellen der Storage
-Instanz verwendet werden. Um einen der anderen skalaren Parameter zu ändern, übergeben Sie benutzerdefinierte RetrySettings
an die StorageOptions
, die zum Erstellen der Storage
-Instanz verwendet werden.
Im folgenden Beispiel erfahren Sie, wie Sie das Wiederholungsverhalten anpassen:
Node.js
Beim Initialisieren von Cloud Storage wird auch eine retryOptions-Konfigurationsdatei initialisiert. Wenn die Optionen nicht überschrieben werden, werden sie in der Konfiguration auf die Standardwerte gesetzt. Um das Standardverhalten für Wiederholungsversuche zu ändern, übergeben Sie bei der Initialisierung die benutzerdefinierte Wiederholungskonfiguration retryOptions
an den Speicherkonstruktor.
Die Node.js-Clientbibliothek kann automatisch Backoff-Strategien verwenden, um Anfragen mit dem Parameter autoRetry
noch einmal zu senden.
Im folgenden Codebeispiel erfahren Sie, wie Sie das Wiederholungsverhalten anpassen.
PHP
Sie können die Standard-Wiederholungsstrategie, die von der PHP-Clientbibliothek verwendet wird, nicht anpassen.
Python
Zum Ändern des Standardverhaltens für Wiederholungsversuche erstellen Sie eine Kopie des google.cloud.storage.retry.DEFAULT_RETRY
-Objekts. Dazu rufen Sie es mit der Methode with_XXX
auf. Die Python-Clientbibliothek verwendet automatisch Backoff-Strategien, um Anfragen zu wiederholen, wenn Sie den Parameter DEFAULT_RETRY
einfügen.
Beachten Sie, dass with_predicate
nicht für Vorgänge unterstützt wird, die Nutzlastdaten abrufen oder senden, z. B. Uploads und Downloads. Es wird empfohlen, Attribute einzeln zu ändern. Weitere Informationen finden Sie in der google-api-core Retry-Referenz.
Zum Konfigurieren Ihrer eigenen bedingten Wiederholungsversuche erstellen Sie ein ConditionalRetryPolicy
-Objekt und verpacken das benutzerdefinierte Retry
-Objekt mit DEFAULT_RETRY_IF_GENERATION_SPECIFIED
, DEFAULT_RETRY_IF_METAGENERATION_SPECIFIED
oder DEFAULT_RETRY_IF_ETAG_IN_JSON
.
Im folgenden Codebeispiel erfahren Sie, wie Sie das Wiederholungsverhalten anpassen.
Ruby
Beim Initialisieren des Speicherclients werden alle Wiederholungskonfigurationen auf die Werte in der obigen Tabelle festgelegt. Um das Standardverhalten für Wiederholungsversuche zu ändern, übergeben Sie die Wiederholungskonfigurationen während der Initialisierung des Storage-Clients.
Übergeben Sie retries
im options
-Parameter des Vorgangs, um die Anzahl der Wiederholungen für einen bestimmten Vorgang zu überschreiben.
REST APIs
Verwenden Sie den exponentiellen Backoff-Algorithmus, um Ihre eigene Wiederholungsstrategie zu implementieren.
Exponentieller Backoff-Algorithmus
Ein exponentieller Backoff-Algorithmus wiederholt Anfragen mit exponentiell zunehmenden Wartezeiten zwischen den Anfragen bis zur maximalen Backoff-Zeit. Im Allgemeinen sollten Sie den exponentiellen Backoff mit Jitter verwenden, um Anfragen zu wiederholen, die sowohl die Antwort- als auch die Idempotenzkriterien erfüllen. Best Practices für die Implementierung automatischer Wiederholungsversuche mit exponentiellem Backoff finden Sie unter Kaskadierende Fehler beheben.
Antimuster für Wiederholungsversuche
Es wird empfohlen, die integrierten Wiederholungsmechanismen nach Möglichkeit zu verwenden oder anzupassen. Weitere Informationen finden Sie unter Wiederholungen anpassen. Unabhängig davon, ob Sie die Standardwiederholungsmechanismen verwenden, sie anpassen oder eine eigene Wiederholungslogik implementieren, ist es wichtig, die folgenden häufigen Antipatterns zu vermeiden, da sie Probleme eher verschlimmern als beheben können.
Wiederholung ohne Backoff
Wenn Sie Anfragen sofort oder mit sehr kurzen Verzögerungen wiederholen, kann dies zu kaskadierenden Fehlern führen, die andere Fehler auslösen können.
So vermeiden Sie das: Implementieren Sie einen exponentiellen Backoff mit Jitter. Bei dieser Strategie wird die Wartezeit zwischen den Wiederholungsversuchen schrittweise erhöht und ein Zufallselement hinzugefügt, um zu verhindern, dass der Dienst durch Wiederholungsversuche überlastet wird.
Nicht-idempotente Vorgänge bedingungslos wiederholen
Wenn Sie Vorgänge, die nicht idempotent sind, wiederholt ausführen, kann dies zu unbeabsichtigten Nebeneffekten führen, z. B. zu unbeabsichtigten Überschreibungen oder Löschungen von Daten.
So vermeiden Sie das: Machen Sie sich mit den Idempotenzmerkmalen der einzelnen Vorgänge vertraut, wie im Abschnitt Idempotenz von Vorgängen beschrieben. Bei nicht idempotenten Vorgängen muss Ihre Wiederholungslogik potenzielle Duplikate verarbeiten können oder Sie sollten Wiederholungen ganz vermeiden. Seien Sie vorsichtig bei Wiederholungsversuchen, die zu Race-Bedingungen führen können.
Nicht behebbare Fehler wiederholen
Alle Fehler als wiederholbar zu behandeln, kann problematisch sein. Einige Fehler, z. B. Autorisierungsfehler oder ungültige Anfragen, sind persistent. Wenn Sie sie wiederholen, ohne die zugrunde liegende Ursache zu beheben, ist das nicht erfolgreich und kann dazu führen, dass Anwendungen in einer Endlosschleife hängen bleiben.
So vermeiden Sie das: Teilen Sie Fehler in vorübergehende (wiederholbare) und dauerhafte (nicht wiederholbare) Fehler ein. Wiederholen Sie nur vorübergehende Fehler wie die HTTP-Codes 408
, 429
und 5xx
oder bestimmte Verbindungsprobleme. Bei permanenten Fehlern sollten Sie sie protokollieren und die zugrunde liegende Ursache entsprechend beheben.
Wiederholungsversuche ignorieren
Unbegrenzte Wiederholungsversuche können dazu führen, dass die Ressourcen in Ihrer Anwendung erschöpft sind oder dass fortlaufend Anfragen an einen Dienst gesendet werden, der sich ohne Eingriff nicht erholen kann.
So vermeiden Sie das: Passen Sie die Wiederholungslimits an die Art Ihrer Arbeitslast an. Bei latenzempfindlichen Arbeitslasten sollten Sie eine maximale Gesamtdauer für Wiederholungsversuche festlegen, um eine rechtzeitige Antwort oder einen rechtzeitigen Fehler zu gewährleisten. Bei Batcharbeitslasten, bei denen längere Wiederholungszeiträume für vorübergehende serverseitige Fehler toleriert werden können, sollten Sie ein höheres Gesamtwiederholungslimit festlegen.
Unnötige Wiederholungen
Wenn Sie zusätzlich zu den vorhandenen Wiederholungsmechanismen eine benutzerdefinierte Wiederholungslogik auf Anwendungsebene hinzufügen, kann dies zu einer übermäßigen Anzahl von Wiederholungsversuchen führen. Wenn Ihre Anwendung beispielsweise einen Vorgang dreimal wiederholt und die zugrunde liegende Clientbibliothek ihn auch dreimal für jeden Versuch Ihrer Anwendung wiederholt, kann es zu neun Wiederholungsversuchen kommen. Wenn Sie viele Wiederholungsversuche für Fehler senden, die nicht wiederholt werden können, kann dies zu einer Drosselung der Anfragen führen, wodurch der Durchsatz aller Arbeitslasten begrenzt wird. Eine hohe Anzahl von Wiederholungsversuchen kann auch die Latenz von Anfragen erhöhen, ohne die Erfolgsrate zu verbessern.
So vermeiden Sie das: Wir empfehlen, die integrierten Wiederholungsmechanismen zu verwenden und zu konfigurieren. Wenn Sie Wiederholungsversuche auf Anwendungsebene implementieren müssen, z. B. für eine bestimmte Geschäftslogik, die sich über mehrere Vorgänge erstreckt, sollten Sie das zugrunde liegende Wiederholungsverhalten genau kennen. Deaktivieren oder begrenzen Sie Wiederholungsversuche in einer der Ebenen, um multiplikative Effekte zu vermeiden.
Nächste Schritte
- Weitere Informationen zu Vorbedingungen für Anfragen