Wiederholungsstrategie

Auf dieser Seite werden Wiederholungsstrategien wie abgeschnittener exponentieller Backoff für fehlgeschlagene Anfragen an Cloud Storage beschrieben.

Übersicht

Viele Cloud Storage-Tools wie die Cloud Console und die meisten Clientbibliotheken verwenden automatisch eine Wiederholungsstrategie. Daher müssen Sie in der Regel keine eigene Strategie implementieren. Wenn Sie eine eigene Wiederholungsstrategie implementieren, sollten Sie den Typ der Anfrage und ihre Idempotenz berücksichtigen, um zu bestimmen, ob die Anfrage wiederholt werden kann. Für Anfragen, die sicher wiederholt werden können, sollten Sie im Allgemeinen den abgeschnittenen exponentiellen Backoff verwenden. Die folgenden Anfragen sind wiederholbare Anfragen:

Alle Anfragen an Cloud Storage, die den HTTP-Antwortcode 5xx zurückgeben, einschließlich Uploads und Downloads von Daten oder Metadaten
Anfragen an Cloud Storage, die den HTTP-Antwortcode 408 oder 429 zurückgeben.
Socket-Zeitüberschreitungen und getrennte TCP-Verbindungen

Weitere Informationen finden Sie in den Status- und Fehlercodes für JSON und XML-Code.

Exponentieller Backoff-Algorithmus

Ein abgeschnittener exponentieller Backoff ist eine Standardstrategie zur Fehlerbehebung für Netzwerkanwendungen, bei der ein Client eine fehlgeschlagene Anfrage regelmäßig noch einmal sendet, wobei die Abstände zwischen den Anfragen immer länger werden.

Ein exponentieller Backoff-Algorithmus wiederholt Anfragen exponentiell und verlängert dabei die Wartezeit zwischen zwei Wiederholungen bis zur maximalen Backoff-Zeit. Ein Beispiel:

Senden Sie eine Anfrage an Cloud Storage.
Wenn die Anfrage fehlschlägt, wartet das System 1 + random_number_milliseconds Sekunden und wiederholt dann die Anfrage.
Wenn die Anfrage fehlschlägt, wartet das System 2 + random_number_milliseconds Sekunden und wiederholt dann die Anfrage.
Wenn die Anfrage fehlschlägt, wartet das System 4 + random_number_milliseconds Sekunden und wiederholt dann die Anfrage.
Und so weiter bis zur maximum_backoff-Zeit.
Setzen Sie die Wartezeit fort und wiederholen Sie den Vorgang bis zu einer maximalen Frist (deadline). Erhöhen Sie jedoch nicht die Wartezeit von maximum_backoff zwischen Wiederholungsversuchen.

wobei

Die Wartezeit beträgt min((2ⁿ +random_number_milliseconds), maximum_backoff), wobei n bei jeder Ausführung (Anfrage) um 1 erhöht wird.
random_number_milliseconds steht für eine zufällige Anzahl von Millisekunden, deren Wert größer oder gleich 1.000 ist. So lassen sich Situationen vermeiden, in denen viele Clients synchronisiert werden und alle gleichzeitig Anfragen wiederholen und diese in synchronisierten Wellen senden. Der Wert von random_number_milliseconds wird nach jeder Anfragewiederholung neu berechnet.
maximum_backoff ist normalerweise 32 oder 64 Sekunden lang. Der geeignete Wert hängt vom jeweiligen Anwendungsfall ab.

Sie können den Vorgang wiederholen, wenn die maximum_backoff-Zeit erreicht wurde. Wir empfehlen jedoch, dass die Anfrage nach einer bestimmten Zeit fehlschlägt, um zu verhindern, dass Ihre Anwendung nicht mehr reagiert. Wenn ein Client beispielsweise eine maximum_backoff-Zeit von 64 Sekunden verwendet, kann er den Vorgang nach Erreichen dieses Werts alle 64 Sekunden noch einmal versuchen. Der Client beendet dann den Vorgang nach einer deadline von 600 Sekunden.

Wie lange Clients zwischen Wiederholungen warten sollten und wie oft sie versuchen sollten, eine Anfrage ein weiteres Mal zu senden, hängt von Ihrem Anwendungsfall und den Netzwerkbedingungen ab. Mobile Clients einer Anwendung müssen unter Umständen mehr Wiederholungen mit längeren Intervallen ausführen als Desktopclients derselben Anwendung.

Wenn die Anfragewiederholungen nach Überschreiten des Werts maximum_backoff plus einer zusätzlichen Frist für Wiederholungen fehlschlagen, melden oder protokollieren Sie einen Fehler mit einer der Methoden, die unter Support und Hilfe aufgeführt werden.

Idempotenz

Um zu bestimmen, ob eine fehlgeschlagene Anfrage an Cloud Storage sicher wiederholt werden kann, sollten Sie prüfen, ob die Anfrage idempotent ist. Das bedeutet, dass der gleiche Vorgang mehrere Male die gleichen Auswirkungen auf den Status der Zielressource hat. Idempotente Vorgänge sind in der Regel sicher für einen Wiederholungsversuch.

Hier einige Beispiele für Bedingungen, die die Idempotenz erfüllen:

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.

So hat beispielsweise eine Anfrage zum Auflisten von Buckets die gleiche Wirkung, auch wenn die Anfrage mehrmals ausgeführt wird. Andererseits ist ein Vorgang wie das Erstellen einer neuen Pub/Sub-Benachrichtigung nicht idempotent, da bei jeder erfolgreichen Anfrage eine neue Benachrichtigungs-ID erstellt wird.

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.

Wiederholungsstrategie pro Cloud Storage-Tool

Klicken Sie auf die folgenden Tabs, um die Empfehlungen zu Wiederholungsstrategien für die einzelnen Cloud Storage-Tools aufzurufen.

Console

Die Cloud Console sendet in Ihrem Namen Anfragen an Cloud Storage und sorgt für die Bearbeitung aller erforderlichen Backoffs.

gsutil

gsutil wiederholt die im Abschnitt Übersicht aufgeführten Fehler, ohne dass Sie etwas zusätzlich unternehmen müssen. Bei anderen Fehlern müssen Sie unter Umständen z. B. folgende Maßnahmen ergreifen:

Ungültige Anmeldedaten oder unzureichende Berechtigungen.
Das Netzwerk ist nicht erreichbar, da Probleme mit der Proxykonfiguration aufgetreten sind.
Einzelne Vorgänge, die in einem Befehl fehlschlagen, wenn das Top-Level-Flag -m verwendet wird.

Bei wiederholbaren Fehlern wiederholt gsutil Anfragen nach der Strategie eines abgeschnittenen binären exponentiellen Backoffs: Standardmäßig führt gsutil Wiederholungsversuche 23 Mal im Verlauf von 1+2+4+8+16+32+60… Sekunden durch, was ungefähr 10 Minuten entspricht.

Wenn eine Anfrage fehlschlägt, warten Sie einen zufälligen Zeitraum zwischen [0....1] Sekunden und wiederholen Sie den Vorgang.
Wenn die Anfrage noch einmal fehlschlägt, warten Sie einen zufälligen Zeitraum zwischen [0...2] Sekunden und versuchen Sie es noch einmal.
Wenn die Anfrage noch einmal fehlschlägt, warten Sie einen zufälligen Zeitraum zwischen [0...4] Sekunden und wiederholen Sie den Vorgang.
Und so weiter, bis zu 23 Wiederholungen, wobei jeder Wiederholungszeitraum durch einen Standardmaximalwert von 60 Sekunden begrenzt ist.

Sie können die Anzahl der Wiederholungen und die maximale Verzögerung für einzelne Wiederholungsversuche konfigurieren, indem Sie die Konfigurationsvariablen num_retries und max_retry_delay im Abschnitt "[Boto]" der Konfigurationsdatei .boto bearbeiten.

Für Datenübertragungen mit den gsutil-Befehlen cp und rsync bietet gsutil zusätzliche Wiederholungsfunktionen in Form von fortsetzbaren Übertragungen.

Clientbibliotheken

C++

In der C++-Clientbibliothek wird exponentieller Backoff standardmäßig verwendet.

C#

In der C#-Clientbibliothek wird exponentieller Backoff standardmäßig verwendet.

Go

In der Go-Clientbibliothek wird exponentieller Backoff standardmäßig verwendet.

Java

In der Java-Clientbibliothek wird exponentieller Backoff standardmäßig verwendet.

Node.js

Die Node.js-Clientbibliothek kann automatisch Backoff-Strategien verwenden, um Anfragen mit dem Parameter autoRetry noch einmal zu senden.

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-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)
Anfängliche Wartezeit	1
Multiplikator für die Wartezeit pro Ausführung	2
Maximale Wartezeit	60
Standardfrist	120

Eine Teilmenge von Vorgängen ist nur idempotent, wenn sie bestimmte optionale Argumente enthält. Vorgänge, bei denen eine Wiederholung bedingt sicher ist, werden nur dann wiederholt, wenn der Bedingungsfall erfolgreich war. Derzeit umfassen diese Bedingungen Folgendes:

DEFAULT_RETRY_IF_GENERATION_SPECIFIED
- Sicher für Wiederholung, wenn generation oder if_generation_match als Argument an die Methode übergeben wurde. Häufig akzeptieren Methoden nur einen dieser beiden Parameter.
DEFAULT_RETRY_IF_METAGENERATION_SPECIFIED
- Sicher für Wiederholung, wenn if_metageneration_match als Argument an die Methode übergeben wurde.
DEFAULT_RETRY_IF_ETAG_IN_JSON
- Es kann wiederholt werden, wenn die Methode etag in den JSON-Anfragetext einfügt. Für HMACKeyMetadata.update() bedeutet dies, dass das ETag für das HMACKeyMetadata-Objekt selbst festgelegt werden muss. Für die set_iam_policy()-Methode in anderen Klassen bedeutet dies, dass das ETag im Argument "policy" festgelegt werden muss, das an die Methode übergeben wird.

Richtlinien für Wiederholungsversuche

Bei Nicht-Medien-Vorgängen, die entweder sicher oder bedingt sicher sind, wird der Methodensignatur ein retry-Parameter hinzugefügt. Die Standardeinstellung für diese Parameter ist eine der folgenden:

DEFAULT_RETRY
DEFAULT_RETRY_IF_GENERATION_SPECIFIED
DEFAULT_RETRY_IF_METAGENERATION_SPECIFIED
DEFAULT_RETRY_IF_ETAG_IN_JSON

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. Beachten Sie, dass with_predicate nicht für Vorgänge unterstützt wird, die Nutzlastdaten abrufen oder senden, z. B. Uploads und Downloads. Wir empfehlen, Attribute einzeln zu ändern. Weitere Informationen finden Sie in der Referenz google-api-core Retry.

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.

Die folgenden Beispiele zeigen benutzerdefinierte Wiederholungsversuche:

blob.reload() verwendet standardmäßig DEFAULT_RETRY. Wenn Sie dies überschreiben möchten, sodass die Funktion überhaupt nicht wiederholt wird, rufen Sie sie als blob.reload(retry=None) auf.
bucket.update() verwendet standardmäßig DEFAULT_RETRY_IF_METAGENERATION_SPECIFIED. Wenn Sie dies überschreiben möchten, damit die Funktion auch dann ausgeführt wird, wenn die Metagenerationsnummer nicht angegeben ist, rufen Sie sie so auf:
```
from google.cloud.storage.retry import DEFAULT_RETRY
bucket.update(retry=DEFAULT_RETRY)
```
bucket.list_blobs() verwendet standardmäßig DEFAULT_RETRY. Um dies zu überschreiben, sodass der API-Aufruf mit einer Frist von 20 Sekunden anstelle der standardmäßigen 120 Sekunden wiederholt wird, rufen Sie sie so auf:
```
from google.cloud.storage.retry import DEFAULT_RETRY
modified_retry = DEFAULT_RETRY.with_deadline(20)
bucket.list_blobs(retry=modified_retry)
```

Ruby

In der Ruby-Clientbibliothek wird exponentieller Backoff standardmäßig verwendet.

REST APIs

Wenn Sie die JSON- oder XML API direkt aufrufen, sollten Sie mit dem exponentiellen Backoff Ihre eigene Wiederholungsstrategie implementieren.

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	Vorgänge
Immer idempotent	Alle get- und list-Anfragen Buckets einfügen oder löschen IAM-Richtlinien und -Berechtigungen für Test-Buckets Aufbewahrungsrichtlinien sperren HMAC-Schlüssel oder Pub/Sub-Benachrichtigungen löschen
Bedingt idempotent	Update-/Patch-Anfragen für Buckets mit `IfMetagenerationMatch` oder ETag als HTTP-Vorbedingung Aktualisierungs-/Patchanfragen für Objekte mit `IfMetagenerationMatch` oder ETag als HTTP-Vorbedingung Bucket-IAM-Richtlinie mit ETag als HTTP-Vorbedingung oder im Ressourcentext festlegen HMAC-Schlüssel mit ETag als HTTP-Vorbedingung oder im Ressourcentext aktualisieren Mit `ifGenerationMatch` Objekte einfügen, kopieren, verfassen oder neu schreiben Objekt mit `ifGenerationMatch` löschen (oder mit einer Generierungsnummer für Objektversionen)
Nie idempotent	HMAC-Schlüssel erstellen Pub/Sub-Benachrichtigung erstellen Patch-/Updateanfragen für Bucket- und Objekt-ACLs oder Standard-Objekt-ACLs erstellen, löschen oder senden