Stratégie de nouvelle tentative

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

De nombreux outils Cloud Storage, tels que Cloud Console et la plupart des bibliothèques clientes, utilisent automatiquement une stratégie de nouvelle tentative. Vous n'avez donc généralement pas besoin d'implémenter les vôtres. Si vous mettez en œuvre votre propre stratégie de nouvelle tentative, deux facteurs déterminent si une requête est sécurisée ou non :

  1. La réponse que vous recevez de la requête.
  2. L'idempotence de la requête.

Pour en savoir plus sur ces facteurs et sur l'algorithme de nouvelle tentative recommandé, consultez la section Mettre en œuvre une stratégie de nouvelles tentatives.

Comment les outils Cloud Storage mettent en œuvre des stratégies de nouvelle tentative

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

gsutil relance les erreurs répertoriées dans la section Réponse sans que vous n'ayez à intervenir. Vous devrez peut-être prendre des mesures pour d'autres erreurs, par exemple celles ci-dessous :

  • Identifiants incorrects ou autorisations insuffisantes

  • Réseau inaccessible en raison d'un problème de configuration du proxy

  • Opérations individuelles qui échouent dans une commande où vous utilisez l'option de niveau supérieur -m.

Pour les erreurs permettant des nouvelles tentatives, gsutil relance les requêtes à l'aide d'une stratégie d'intervalle exponentiel tronqué entre les tentatives. Par défaut, gsutil effectue 23 nouvelles tentatives sur à des intervalles de 1+2+4+8+16+32+60... secondes pour une durée totale d'environ 10 minutes :

  • Si une requête échoue, attendez une période aléatoire comprise entre [0..1] secondes et réessayez ;
  • si la requête échoue à nouveau, attendez une période aléatoire comprise entre [0..2] secondes et réessayez ;
  • si la requête échoue à nouveau, attendez une période aléatoire comprise entre [0..4] secondes et réessayez ;
  • et ainsi de suite jusqu'à 23 nouvelles tentatives, chaque période de nouvelle tentative étant limitée par une durée maximum par défaut de 60 secondes.

Vous pouvez configurer le nombre de nouvelles tentatives et le délai maximal entre chaque tentative en modifiant les variables de configuration num_retries et max_retry_delay dans la section "[Boto]" du fichier de configuration .boto.

Bibliothèques clientes

C++

Comportement par défaut des nouvelles tentatives

Par défaut, les opérations autorisent les nouvelles tentatives pour les codes d'erreur HTTP suivants, ainsi que pour les erreurs de socket indiquant que la connexion a été perdue ou n'a jamais été établie.

  • 408 Request Timeout
  • 429 Too Many Requests
  • 500 Internal Server Error
  • 502 Bad Gateway
  • 503 Service Unavailable
  • 504 Gateway Timeout

Tous les paramètres de la bibliothèque C++ concernant l'intervalle exponentiel entre les tentatives et les nouvelles tentatives sont configurables. Si les algorithmes mis en œuvre dans la bibliothèque ne répondent pas à vos besoins, vous pouvez fournir un code personnalisé pour mettre en œuvre vos propres stratégies.

Paramètre Valeur par défaut
Réessayer automatiquement Vrai
Durée maximale de nouvelle tentative d'exécution d'une requête 15 minutes
Délai d'attente initial (intervalle entre les tentatives) 1 seconde
Multiplicateur de la durée d'attente par itération 2
Durée d'attente maximale 5 minutes

Par défaut, la bibliothèque C++ relance toutes les opérations comportant des erreurs récupérables, même celles qui ne sont jamais idempotentes et sont susceptibles de supprimer ou créer plusieurs ressources lorsqu'elles sont répétées plusieurs fois avec succès. Pour ne relancer que les opérations idempotentes, utilisez google::cloud::storage::StrictIdempotencyPolicy.

Personnaliser les nouvelles tentatives

Pour personnaliser le comportement des nouvelles tentatives, fournissez des valeurs pour les options suivantes lorsque vous initialisez l'objet google::cloud::storage::Client :

  • google::cloud::storage::RetryPolicyOption : la bibliothèque fournit les classes google::cloud::storage::LimitedErrorCountRetryPolicy et google::cloud::storage::LimitedTimeRetryPolicy. Vous pouvez fournir votre propre classe, qui doit mettre en œuvre l'interface google::cloud::RetryPolicy.

  • google::cloud::storage::BackoffPolicyOption : la bibliothèque fournit la classe google::cloud::storage::ExponentialBackoffPolicy. Vous pouvez fournir votre propre classe, qui doit mettre en œuvre l'interface google::cloud::storage::BackoffPolicy.

  • google::cloud::storage::IdempotencyPolicyOption : la bibliothèque fournit les classes google::cloud::storage::StrictIdempotencyPolicy et google::cloud::storage::AlwaysRetryIdempotencyPolicy. Vous pouvez fournir votre propre classe, qui doit mettre en œuvre l'interface google::cloud::storage::IdempotencyPolicy.

namespace gcs = ::google::cloud::storage;
// Create the client configuration:
auto options = google::cloud::Options{};
// Retries only idempotent operations.
options.set<gcs::IdempotencyPolicyOption>(
    gcs::StrictIdempotencyPolicy().clone());
// On error, it backs off for 1 second, then 3 seconds, then 9 seconds, etc.
// The backoff time never grows larger than 1 minute. The strategy introduces
// jitter around the backoff delay.
options.set<gcs::BackoffPolicyOption>(
    gcs::ExponentialBackoffPolicy(
        /*initial_delay=*/std::chrono::seconds(1),
        /*maximum_delay=*/std::chrono::minutes(1),
        /*scaling=*/3.0)
        .clone());
// Retries all operations for up to 5 minutes, including any backoff time.
options.set<gcs::RetryPolicyOption>(
    gcs::LimitedTimeRetryPolicy(std::chrono::minutes(5)).clone());
return gcs::Client(std::move(options));

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

Comportement par défaut des nouvelles tentatives

Par défaut, les opérations sont compatibles avec les nouvelles tentatives pour les erreurs suivantes :

  • Erreurs de connexion :
    • Connection reset by peer : cela signifie que GCP a réinitialisé la connexion.
    • Unexpected connection closure : cela signifie que GCP a fermé la connexion.
  • Codes HTTP :
    • 408 Request Timeout
    • 429 Too Many Requests
    • 500 Internal Server Error
    • 502 Bad Gateway
    • 503 Service Unavailable
    • 504 Gateway Timeout

Tous les paramètres de la bibliothèque Java concernant l'intervalle exponentiel entre les tentatives sont configurables. Par défaut, les opérations via Java utilisent les paramètres suivants pour un intervalle exponentiel entre les tentatives :

Paramètre Valeur par défaut (en secondes)
Réessayer automatiquement si idempotent
Nombre maximal de tentatives 6
Délai initial avant une nouvelle tentative 1 seconde
Multiplicateur de délai avant une nouvelle tentative 2.0
Délai maximal avant une nouvelle tentative 32 secondes
Délai avant expiration total 50 secondes
Délai RPC avant expiration initial 50 secondes
Multiplicateur de délai RPC avant expiration 1.0
Délai RPC avant expiration maximal 50 secondes
Délai de connexion expiré 20 secondes
Délai avant expiration de la lecture 20 secondes

Pour en savoir plus sur les paramètres ci-dessus, consultez la documentation de référence Java pour RetrySettings.Builder et HttpTransportOptions.Builder.

Il existe un sous-ensemble d'opérations Java idempotentes sous conditions (sous conditions, elles peuvent être relancées en toute sécurité). Ces opérations n'effectuent de nouvelles tentatives que si elles incluent des arguments spécifiques :

  • ifGenerationMatch ou generation

    • Vous pouvez effectuer de nouvelles tentatives si ifGenerationMatch ou generation a été transmis en tant qu'option à la méthode.

  • ifMetagenerationMatch

    • Peut être relancée en toute sécurité si le paramètre ifMetagenerationMatch a été transmis en tant qu'option.

StorageOptions.setStorageRetryStrategy est défini par défaut sur StorageRetryStrategy#getDefaultStorageRetryStrategy. Reportez-vous à la section Personnaliser les tentatives ci-dessous pour obtenir des exemples montrant comment modifier le comportement des nouvelles tentatives par défaut.

Personnaliser les nouvelles tentatives

Lorsque vous initialisez Storage, une instance de RetrySettings est également initialisée. Sauf si elles sont remplacées, les options de RetrySettings sont définies sur les valeurs du tableau ci-dessus. Pour modifier le comportement par défaut des nouvelles tentatives automatiques, transmettez le StorageRetryStrategy personnalisé au StorageOptions utilisé pour créer l'instance Storage. Pour modifier l'un des autres paramètres scalaires, transmettez un RetrySettings personnalisé au StorageOptions utilisé pour créer l'instance Storage.

Consultez l'exemple suivant pour découvrir comment personnaliser le comportement des nouvelles tentatives :


import com.google.api.gax.retrying.RetrySettings;
import com.google.cloud.storage.BlobId;
import com.google.cloud.storage.Storage;
import com.google.cloud.storage.StorageOptions;
import com.google.cloud.storage.StorageRetryStrategy;
import org.threeten.bp.Duration;

public final class ConfigureRetries {
  public static void main(String[] args) {
    String bucketName = "my-bucket";
    String blobName = "blob/to/delete";
    deleteBlob(bucketName, blobName);
  }

  static void deleteBlob(String bucketName, String blobName) {
    // Customize retry behavior
    RetrySettings retrySettings =
        StorageOptions.getDefaultRetrySettings()
            .toBuilder()
            // Set the max number of attempts to 10 (initial attempt plus 9 retries)
            .setMaxAttempts(10)
            // Set the backoff multiplier to 3.0
            .setRetryDelayMultiplier(3.0)
            // Set the max duration of all attempts to 5 minutes
            .setTotalTimeout(Duration.ofMinutes(5))
            .build();

    StorageOptions alwaysRetryStorageOptions =
        StorageOptions.newBuilder()
            // Customize retry so all requests are retried even if they are non-idempotent.
            .setStorageRetryStrategy(StorageRetryStrategy.getUniformStorageRetryStrategy())
            // provide the previously configured retrySettings
            .setRetrySettings(retrySettings)
            .build();

    // Instantiate a client
    Storage storage = alwaysRetryStorageOptions.getService();

    // Delete the blob
    BlobId blobId = BlobId.of(bucketName, blobName);
    boolean success = storage.delete(blobId);

    System.out.printf(
        "Deletion of Blob %s completed %s.%n", blobId, success ? "successfully" : "unsuccessfully");
  }
}

Node.js

Comportement par défaut des nouvelles tentatives

Par défaut, les opérations sont compatibles avec les nouvelles tentatives pour les codes d'erreur suivants :

  • Erreurs de connexion :
    • EAI_again : erreur de résolution DNS. Pour en savoir plus, cliquez ici.
    • Connection reset by peer : cela signifie que GCP a réinitialisé la connexion.
    • Unexpected connection closure : cela signifie que GCP a fermé la connexion.
  • Codes HTTP :
    • 408 Request Timeout
    • 429 Too Many Requests
    • 500 Internal Server Error
    • 502 Bad Gateway
    • 503 Service Unavailable
    • 504 Gateway Timeout

Tous les paramètres de la bibliothèque Node.js concernant l'intervalle exponentiel entre les tentatives sont configurables. Par défaut, les opérations via Node.js utilisent les paramètres suivants pour un intervalle exponentiel entre les tentatives :

Paramètre Valeur par défaut (en secondes)
Réessayer automatiquement Vrai
Nombre maximal de nouvelles tentatives 3
Durée d'attente initiale 1 seconde
Multiplicateur de la durée d'attente par itération 2
Durée d'attente maximale 64 secondes
Deadline par défaut 600 secondes

Il existe un sous-ensemble d'opérations Node.js idempotentes sous conditions (sous conditions, elles peuvent être relancées en toute sécurité). Ces opérations n'effectuent de nouvelles tentatives que si elles incluent des arguments spécifiques, également appelés conditions préalables :

  • ifGenerationMatch ou generation

    • Vous pouvez effectuer de nouvelles tentatives si ifGenerationMatch ou generation a été transmis en tant qu'option à la méthode. Les méthodes n'acceptent souvent que l'un de ces deux paramètres.

  • ifMetagenerationMatch

    • Peut être relancée en toute sécurité si le paramètre ifMetagenerationMatch a été transmis en tant qu'option.

retryOptions.idempotencyStrategy est défini par défaut sur IdempotencyStrategy.RetryConditional. Reportez-vous à la section Personnaliser les tentatives ci-dessous pour obtenir des exemples montrant comment modifier le comportement des nouvelles tentatives par défaut.

Personnaliser les nouvelles tentatives

Lorsque vous initialisez Cloud Storage, un fichier de configuration retryOptions est également initialisé. Les options de la configuration sont définies sur les valeurs du tableau ci-dessus sauf si elles sont remplacées. Pour modifier le comportement par défaut des nouvelles tentatives, transmettez la configuration de nouvelle tentative personnalisée retryOptions au constructeur de stockage lors de l'initialisation. La bibliothèque cliente Node.js peut utiliser automatiquement utiliser des stratégies d'intervalle exponentiel entre les tentatives pour relancer des requêtes avec le paramètre autoRetry.

Consultez l'exemple de code suivant pour découvrir comment personnaliser le comportement des nouvelles tentatives.

/**
 * TODO(developer): Uncomment the following lines before running the sample.
 */
// The ID of your GCS bucket
// const bucketName = 'your-unique-bucket-name';

// The ID of your GCS file
// const fileName = 'your-file-name';

// Imports the Google Cloud client library
const {Storage} = require('@google-cloud/storage');

// Creates a client
const storage = new Storage({
  retryOptions: {
    // If this is false, requests will not retry and the parameters
    // below will not affect retry behavior.
    autoRetry: true,
    // The multiplier by which to increase the delay time between the
    // completion of failed requests, and the initiation of the subsequent
    // retrying request.
    retryDelayMultiplier: 3,
    // The total time between an initial request getting sent and its timeout.
    // After timeout, an error will be returned regardless of any retry attempts
    // made during this time period.
    totalTimeout: 500,
    // The maximum delay time between requests. When this value is reached,
    // retryDelayMultiplier will no longer be used to increase delay time.
    maxRetryDelay: 60,
    // The maximum number of automatic retries attempted before returning
    // the error.
    maxRetries: 5,
    // Will respect other retry settings and attempt to always retry
    // conditionally idempotent operations, regardless of precondition
    idempotencyStrategy: IdempotencyStrategy.RetryAlways,
  },
});
console.log(
  'Functions are customized to be retried according to the following parameters:'
);
console.log(`Auto Retry: ${storage.retryOptions.autoRetry}`);
console.log(
  `Retry delay multiplier: ${storage.retryOptions.retryDelayMultiplier}`
);
console.log(`Total timeout: ${storage.retryOptions.totalTimeout}`);
console.log(`Maximum retry delay: ${storage.retryOptions.maxRetryDelay}`);
console.log(`Maximum retries: ${storage.retryOptions.maxRetries}`);
console.log(
  `Idempotency strategy: ${storage.retryOptions.idempotencyStrategy}`
);

async function deleteFileWithCustomizedRetrySetting() {
  await storage.bucket(bucketName).file(fileName).delete();
  console.log(`File ${fileName} deleted with a customized retry strategy.`);
}

deleteFileWithCustomizedRetrySetting();

PHP

Par défaut, la bibliothèque cliente PHP utilise l'intervalle exponentiel entre les tentatives.

Python

Comportement par défaut des nouvelles tentatives

Par défaut, les opérations sont compatibles avec les nouvelles tentatives pour les codes d'erreur suivants :

  • Erreurs de connexion :
    • requests.exceptions.ConnectionError
    • requests.exceptions.ChunkedEncodingError (uniquement pour les opérations de récupération ou d'envoi de données de charge utile à des objets, telles que les importations et les téléchargements)
    • ConnectionError
  • Codes HTTP :
    • 408 Request Timeout
    • 429 Too Many Requests
    • 500 Internal Server Error
    • 502 Bad Gateway
    • 503 Service Unavailable
    • 504 Gateway Timeout

Les opérations via Python utilisent les paramètres par défaut suivants pour l'intervalle exponentiel entre les tentatives :

Paramètre Valeur par défaut (en secondes)
Durée d'attente initiale 1
Multiplicateur de la durée d'attente par itération 2
Durée d'attente maximale 60
Deadline par défaut 120

Il existe un sous-ensemble d'opérations Python idempotentes sous conditions (sous conditions, elles peuvent être relancées en toute sécurité). Ces opérations n'effectuent de nouvelles tentatives que si une condition est satisfaite :

  • DEFAULT_RETRY_IF_GENERATION_SPECIFIED

    • Vous pouvez effectuer de nouvelles tentatives si generation ou if_generation_match a été transmis en tant qu'argument à la méthode. Les méthodes n'acceptent souvent que l'un de ces deux paramètres.

  • 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.

  • DEFAULT_RETRY_IF_ETAG_IN_JSON

    • Vous pouvez effectuer de nouvelles tentatives si la méthode insère un etag dans le corps de la requête JSON. Pour HMACKeyMetadata.update(), cela signifie que l'eTag doit être défini sur l'objet HMACKeyMetadata lui-même. Pour la méthode set_iam_policy() sur d'autres classes, cela signifie que l'eTag doit être défini dans l'argument "policy" transmis à la méthode.

Personnaliser les nouvelles tentatives

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. La bibliothèque cliente Python utilise automatiquement des stratégies d'intervalle exponentiel entre les tentatives pour relancer des requêtes si vous incluez le paramètre DEFAULT_RETRY.

Notez que with_predicate n'est pas compatible avec les opérations de récupération ou d'envoi de données de charge utile à des objets, telles que les importations et les téléchargements. 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.

Consultez l'exemple de code suivant pour découvrir comment personnaliser le comportement des nouvelles tentatives.

from google.cloud import storage
from google.cloud.storage.retry import DEFAULT_RETRY

def configure_retries(bucket_name, blob_name):
    """Configures retries with customizations."""
    # The ID of your GCS bucket
    # bucket_name = "your-bucket-name"
    # The ID of your GCS object
    # blob_name = "your-object-name"

    storage_client = storage.Client()
    bucket = storage_client.bucket(bucket_name)
    blob = bucket.blob(blob_name)

    # Customize retry with a deadline of 500 seconds (default=120 seconds).
    modified_retry = DEFAULT_RETRY.with_deadline(500.0)
    # Customize retry with an initial wait time of 1.5 (default=1.0).
    # Customize retry with a wait time multiplier per iteration of 1.2 (default=2.0).
    # Customize retry with a maximum wait time of 45.0 (default=60.0).
    modified_retry = modified_retry.with_delay(initial=1.5, multiplier=1.2, maximum=45.0)

    # blob.delete() uses DEFAULT_RETRY_IF_GENERATION_SPECIFIED by default.
    # Override with modified_retry so the function retries even if the generation
    # number is not specified.
    print(
        f"The following library method is customized to be retried according to the following configurations: {modified_retry}"
    )

    blob.delete(retry=modified_retry)
    print("Blob {} deleted with a customized retry strategy.".format(blob_name))

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 nouvelles tentatives.

Mise en œuvre d'une stratégie de nouvelle tentative

Cette section décrit les facteurs à prendre en compte lors de la création de votre propre stratégie de nouvelles tentatives, ainsi que l'algorithme de nouvelles tentatives recommandé à utiliser.

Réponse

La réponse que vous recevez de votre requête indique s'il est utile de réessayer la requête ou non. Les réponses correspondant à des problèmes temporaires peuvent généralement faire l'objet d'une nouvelle tentative. En revanche, une réponse associée à des erreurs permanentes indique que vous devez apporter des modifications, par exemple au niveau des autorisations ou de la configuration, avant de pouvoir relancer la requête. Les réponses suivantes traduisent des problèmes temporaires, pour lesquels il est utile de réessayer :

  • Codes de réponse HTTP 408, 429 et 5xx
  • 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.

Idempotence

Une requête est dite idempotente si elle peut être effectuée à plusieurs reprises et toujours laisser la ressource qu'elle cible dans le même état final. Par exemple, une requête visant à répertorier des éléments est toujours idempotente, car ces requêtes ne modifient pas les ressources. En revanche, la création d'une notification Pub/Sub n'est jamais idempotente, car elle crée un ID de notification chaque fois que la requête aboutit.

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.

Lorsque vous recevez une réponse permettant une nouvelle tentative, vous devez tenir compte de l'idempotence de la requête, car la répétition de requêtes non idempotentes peut entraîner des conditions de concurrence et d'autres conflits.

Idempotence conditionnelle

Un sous-ensemble de requêtes est idempotent sous conditions, ce qui signifie que les requêtes ne sont idempotentes que si elles incluent des arguments facultatifs spécifiques. Les opérations soumises à une règle de sécurité doivent être relancées par défaut uniquement si la condition est remplie. Cloud Storage accepte les conditions préalables et les ETag comme conditions pour les requêtes.

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 idempotente
  • Toutes les requêtes get et list
  • Insérer ou supprimer des buckets
  • Tester les stratégies et autorisations IAM d'un bucket
  • Verrouiller les règles de conservation
  • Supprimer une clé HMAC ou une notification Pub/Sub
Idempotente sous conditions
  • Requêtes de mise à jour/correctif pour les buckets avec IfMetagenerationMatch ou ETag comme condition préalable HTTP
  • Requêtes de mise à jour/correctif pour les objets avec IfMetagenerationMatch ou ETag comme condition préalable HTTP
  • Définir une stratégie IAM de bucket avec un eTag en tant que condition préalable HTTP ou dans le corps de la ressource
  • Mettre à jour une clé HMAC avec un eTag en tant que condition préalable HTTP ou dans le corps de la ressource
  • Insérer, copier, rédiger ou réécrire des objets avec ifGenerationMatch
  • Supprimer un objet avec ifGenerationMatch (ou avec un numéro de génération pour les versions d'objet)
Jamais idempotente
  • Créer une clé HMAC
  • Créer une notification Pub/Sub
  • Créer, supprimer ou envoyer des requêtes de correctif/mise à jour pour les LCA de buckets et d'objets, ou pour des LCA d'objet par défaut

Algorithme de l'intervalle exponentiel entre les tentatives

Pour les requêtes qui répondent à la fois aux critères de réponse et d'idempotence, vous devez généralement utiliser un intervalle exponentiel entre les tentatives tronqué.

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 :

  1. Envoyez une requête à Cloud Storage.

  2. Si la requête échoue, attendez 1 + random_number_milliseconds secondes, puis effectuez une nouvelle tentative.

  3. Si la requête échoue, attendez 2 + random_number_milliseconds secondes, puis effectuez une nouvelle tentative.

  4. Si la requête échoue, attendez 4 + random_number_milliseconds secondes, puis effectuez une nouvelle tentative.

  5. Poursuivez ainsi jusqu'à atteindre la valeur maximum_backoff.

  6. Continuez d'attendre et de réessayer jusqu'à une durée maximale (deadline) mais n'augmentez pas le délai d'attente maximum_backoff entre les nouvelles tentatives.

où :

  • Le temps d'attente correspond à min((2n +random_number_milliseconds), maximum_backoff), avec n 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 effectuent tous une nouvelle tentative au même moment, envoyant des requêtes par vagues synchronisées. La valeur de random_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.

Étape suivante