Cette page décrit les stratégies de nouvelle tentative, telles que l'intervalle exponentiel tronqué entre les tentatives, pour les requêtes envoyées à Cloud Storage ayant échoué.
Présentation
Pour déterminer si vous souhaitez relancer une requête ayant échoué vers Cloud Storage, tenez compte du type de la requête et son idempotence, qui détermine si une nouvelle tentative de l'opération peut être effectuée sans danger. En général, vous devez utiliser un intervalle exponentiel tronqué entre les tentatives pour relancer les types de requêtes suivants:
toutes les requêtes adressées à Cloud Storage qui renvoient les codes de réponse HTTP
5xx
et429
, y compris les importations et les téléchargements de données ou de métadonnées ;les importations avec reprise qui renvoient des codes de réponse HTTP
408
;les délais d'expiration de sockets et les déconnexions TCP.
Pour en savoir plus, consultez les codes d'état et d'erreur pour JSON et XML.
Algorithme de l'intervalle exponentiel entre les tentatives
L'intervalle exponentiel entre les tentatives tronqué est une stratégie standard de traitement des erreurs pour les applications réseau, où un client relance régulièrement une requête ayant échoué en observant des délais croissants entre les tentatives.
Un algorithme d'intervalle exponentiel entre les tentatives relance les requêtes de manière exponentielle, en augmentant le temps d'attente entre les tentatives jusqu'à ce que la durée maximale de l'intervalle exponentiel soit atteinte. Voici un exemple :
Envoyez une requête à Cloud Storage.
Si la requête échoue, attendez 1 +
random_number_milliseconds
secondes, puis effectuez une nouvelle tentative.Si la requête échoue, attendez 2 +
random_number_milliseconds
secondes, puis effectuez une nouvelle tentative.Si la requête échoue, attendez 4 +
random_number_milliseconds
secondes, puis effectuez une nouvelle tentative.Poursuivez ainsi jusqu'à atteindre la valeur
maximum_backoff
.Continuez à attendre et à réessayer jusqu'à une durée maximale (
deadline
), mais n'augmentez pas le délai d'attentemaximum_backoff
entre les nouvelles tentatives.
où :
Le temps d'attente correspond à min((2n +
random_number_milliseconds
),maximum_backoff
), avecn
incrémenté de 1 pour chaque itération (requête).random_number_milliseconds
correspond à un nombre aléatoire de millisecondes inférieur ou égal à 1 000. Cela permet d'éviter les cas où de nombreux clients sont synchronisés et qu'ils effectuent tous deux de nouvelles à la fois, en envoyant des requêtes par vagues synchronisées. La valeur derandom_number_milliseconds
est recalculée après chaque nouvelle tentative de la requête.La valeur
maximum_backoff
est généralement définie sur 32 ou 64 secondes. La valeur appropriée dépend du cas d'utilisation.
Vous pouvez continuer à effectuer des nouvelles tentatives lorsque vous atteignez le délai maximum_backoff
, mais nous vous recommandons d'abandonner votre requête après un certain temps d'échec afin d'éviter que votre application ne cesse de répondre. Par exemple, si un client utilise un délai maximum_backoff
de 64 secondes, une fois celui-ci atteint, il peut effectuer une nouvelle tentative toutes les 64 secondes. Le client arrête ensuite de nouvelles tentatives après un temps limite deadline
de 600 secondes.
Le temps d'attente des clients entre les tentatives et le nombre de tentatives qu'ils peuvent effectuer dépendent du cas d'utilisation et des conditions du réseau. Par exemple, les clients mobiles d'une application peuvent avoir besoin d'effectuer davantage de tentatives et à des intervalles plus longs que les clients de bureau de la même application.
Si les nouvelles tentatives de requête échouent après le dépassement de la valeur maximum_backoff
plus tout temps supplémentaire autorisé pour les nouvelles tentatives, signalez ou enregistrez une erreur à l'aide de l'une des méthodes répertoriées sur la page Assistance.
Idempotence
Pour déterminer si vous pouvez réessayer d'envoyer une requête ayant échoué à Cloud Storage, vérifiez si la requête est idempotente, ce qui signifie que l'application d'une même opération à plusieurs reprises a le même effet sur l'état de la ressource ciblée. Les opérations idempotentes peuvent généralement être relancées en toute sécurité.
Voici des exemples de conditions satisfaisant l'idempotence:
L'opération a le même effet observable sur la ressource ciblée, même lorsqu'elle des requêtes y sont constamment envoyées.
L'opération ne peut aboutir qu'une seule fois.
Cette opération n'a aucun effet observable sur l'état de la ressource ciblée.
Par exemple, une requête de liste de buckets aura le même effet même si la requête aboutit plusieurs fois. En revanche, une opération telle que la création d'une notification Pub/Sub n'est pas idempotente, car elle crée un ID de notification chaque fois que la requête aboutit.
idempotence conditionnelle
Un sous-ensemble de requêtes est idempotent sous conditions, ce qui signifie qu'elles ne sont idempotentes que si elles incluent des arguments facultatifs spécifiques. Les opérations qui peuvent être relancées en toute sécurité sous certaines conditions doivent être relancées par défaut uniquement si la condition est remplie. Cloud Storage accepte les conditions préalables et les ETag comme cas de condition pour les requêtes.
Stratégie de nouvelle tentative par outil Cloud Storage
Cliquez sur les onglets ci-dessous pour afficher les recommandations de stratégie de nouvelle tentative pour chaque outil Cloud Storage.
Console
Cloud Console envoie des requêtes à Cloud Storage en votre nom et gère tout intervalle nécessaire entre les tentatives.
gsutil
Pour afficher la stratégie de nouvelle tentative pour gsutil, consultez la section Stratégie de gestion des tentatives.
Bibliothèques clientes
C++
Par défaut, la bibliothèque cliente C++ utilise l'intervalle exponentiel entre les tentatives.
C#
Par défaut, la bibliothèque cliente C# utilise un intervalle exponentiel entre les tentatives.
Go
Par défaut, la bibliothèque cliente Go utilise l'intervalle exponentiel entre les tentatives.
Java
Par défaut, la bibliothèque cliente Java utilise l'intervalle exponentiel entre les tentatives.
Node.js
Node.js peut utiliser automatiquement des stratégies d'intervalle exponentiel entre les tentatives pour relancer des requêtes avec le paramètre autoRetry
.
PHP
Par défaut, la bibliothèque cliente PHP utilise l'intervalle exponentiel entre les tentatives.
Python
Pour la stratégie de nouvelle tentative, la bibliothèque cliente Python fait la distinction entre les opérations multimédias et non multimédias:
Les opérations multimédias incluent toutes les actions qui récupèrent ou envoient des données de charge utile aux objets. Par exemple, cela inclut toutes les méthodes d'un
Blob
commençant par les mots "importer" ou "télécharger", ainsi queClient.download_blob_to_file
.Les opérations non multimédias sont des actions qui gèrent uniquement les métadonnées des objets.
Par défaut, les opérations multimédias et non multimédias sont compatibles avec les nouvelles tentatives pour les codes d'erreur suivants:
- Erreurs de connexion :
requests.exceptions.ConnectionError
requests.exceptions.ChunkedEncodingError
(appels d'API multimédia uniquement)
- Codes HTTP :
429 Too Many Requests
500 Internal Server Error
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
508 Resource Limit Exceeded
Les opérations via Python utilisent les paramètres par défaut suivants pour l'intervalle exponentiel entre les tentatives:
Réglage par défaut | Appels multimédias | Appels non multimédias |
---|---|---|
Temps d'attente initial (secondes) | 1 | 1 |
Multiplicateur de temps par itération (secondes) | 2 | 2 |
Temps d'attente maximal (secondes) | 64 | 60 |
Délai par défaut (secondes) | 600 | 120 |
Gigue mise en œuvre | Oui | Non |
Un sous-ensemble des opérations multimédias et non multimédias ne peut être idempotent que s'il inclut des arguments facultatifs spécifiques. Les opérations qui peuvent être relancées en toute sécurité sous certaines conditions ne sont relancées par défaut que si le cas de conditions est rempli. Actuellement, ces conditions incluent les suivantes:
DEFAULT_RETRY_IF_GENERATION_SPECIFIED
- Vous pouvez lancer une nouvelle tentative si
if generation
ouif_generation_match
est transmis à la méthode en tant qu'argument. Les méthodes n'acceptent souvent que l'un de ces deux paramètres.
- Vous pouvez lancer une nouvelle tentative si
DEFAULT_RETRY_IF_METAGENERATION_SPECIFIED
- Vous pouvez effectuer de nouvelles tentatives si
if_metageneration_match
a été transmis en tant qu'argument à la méthode.
- Vous pouvez effectuer de nouvelles tentatives si
DEFAULT_RETRY_IF_ETAG_IN_JSON
- Vous pouvez réessayer si la méthode insère un
etag
dans le corps de la requête JSON. PourHMACKeyMetadata.update()
, cela signifie que eTag doit être défini sur l'objetHMACKeyMetadata
lui-même. Pour la méthodeset_iam_policy()
sur d'autres classes, cela signifie que l'ETag doit être défini dans l'argument "policy" transmis à la méthode.
- Vous pouvez réessayer si la méthode insère un
Stratégies de nouvelle tentative pour les opérations multimédias
Pour les opérations multimédias, vous pouvez configurer l'argument num_retries
pour les méthodes d'importation afin de spécifier le nombre de nouvelles tentatives d'importation. Par défaut, seules les importations présentant la condition if_metageneration_match
sont réessayées pour garantir l'idempotence. La définition de l'argument num_retries
remplace le comportement par défaut et garantit les nouvelles tentatives même si la condition if_metageneration_match
n'est pas spécifiée.
Stratégies de nouvelle tentative pour les opérations non multimédias
Un paramètre retry
est ajouté à la signature de la méthode pour les opérations non multimédias qui peuvent être relancées en toute sécurité ou sous certaines conditions. La valeur par défaut pour ces paramètres est l'une des suivantes:
DEFAULT_RETRY
DEFAULT_RETRY_IF_GENERATION_SPECIFIED
DEFAULT_RETRY_IF_METAGENERATION_SPECIFIED
DEFAULT_RETRY_IF_ETAG_IN_JSON
Pour modifier le comportement de nouvelle tentative par défaut, créez une copie de l'objet google.cloud.storage.retry.DEFAULT_RETRY
en l'appelant avec une méthode with_XXX
. Par exemple, pour modifier le délai par défaut à 30 secondes, transmettez retry=DEFAULT_RETRY.with_deadline(30)
. Nous vous recommandons de modifier les attributs un par un. Pour en savoir plus, consultez la documentation de référence sur google-api-core Retry.
Pour configurer votre propre nouvelle tentative conditionnelle, créez un objet ConditionalRetryPolicy
et encapsulez votre objet Retry
personnalisé avec DEFAULT_RETRY_IF_GENERATION_SPECIFIED
, DEFAULT_RETRY_IF_METAGENERATION_SPECIFIED
, ou DEFAULT_RETRY_IF_ETAG_IN_JSON
.
Voici des exemples de nouvelles tentatives conditionnelles personnalisées:
blob.reload()
utiliseDEFAULT_RETRY
par défaut. Pour ignorer ce comportement afin que la fonction ne soit pas réessayée, appelez-la sous la formeblob.reload(retry=None)
.bucket.update()
utiliseDEFAULT_RETRY_IF_METAGENERATION_SPECIFIED
par défaut. Pour éviter cela, afin que la fonction réessaie même si le numéro de métagénération n'est pas spécifié, appelez-la comme suit:from google.cloud.storage.retry import DEFAULT_RETRY bucket.update(retry=DEFAULT_RETRY)
bucket.list_blobs()
utiliseDEFAULT_RETRY
par défaut. Pour remplacer ce paramètre de sorte que l'appel d'API effectue une nouvelle tentative avec un délai de 20 secondes au lieu de 120 secondes par défaut, appelez-le comme suit:from google.cloud.storage.retry import DEFAULT_RETRY modified_retry = DEFAULT_RETRY.with_deadline(20) bucket.list_blobs(retry=modified_retry)
Ruby
Par défaut, la bibliothèque cliente Ruby utilise l'intervalle exponentiel entre les tentatives.
API REST
Lorsque vous appelez directement l'API JSON ou XML, vous devez utiliser l'algorithme d'intervalle exponentiel entre les tentatives pour mettre en œuvre votre propre stratégie de répétition des tentatives.
Idempotence des opérations
Le tableau suivant répertorie les opérations Cloud Storage qui entrent dans chaque catégorie d'idempotence.
Idempotence | Opérations |
---|---|
Toujours idempotent |
|
idempotente sous conditions |
|
Jamais idempotente |
|
Étape suivante
- Découvrez comment relancer des requêtes dans le service de transfert de stockage avec Java ou Python.
- En savoir plus sur les conditions préalables et les numéros de génération