Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Comportement de nouvelle tentative

Le comportement des nouvelles tentatives inclut les paramètres relatifs à la manière dont la SDKs tentative de reprise après un échec résultant de demandes adressées à Services AWS.

Choix entre les standard modes et adaptive nouvelle tentative

Nous vous recommandons d'utiliser le mode standard nouvelle tentative, sauf si vous êtes certain que votre utilisation vous convient le mieux. adaptive

Si vous choisissez d'utiliser adaptive le mode, votre application doit créer des clients conçus en fonction de chaque ressource susceptible d'être limitée. Dans ce cas, une ressource est plus fine que de simplement penser à chacune d'elles Service AWS. Services AWS peuvent avoir des dimensions supplémentaires qu'ils utilisent pour limiter les demandes. Prenons l'exemple du service Amazon DynamoDB. DynamoDB utilise Région AWS plus la table accessible pour limiter les demandes. Cela signifie qu'une table à laquelle votre code accède peut être plus limitée que d'autres. Si votre code utilise le même client pour accéder à toutes les tables et que les demandes adressées à l'une de ces tables sont limitées, le mode de nouvelle tentative adaptatif réduira le taux de demandes pour toutes les tables. Votre code doit être conçu pour avoir un client par egion-and-table paire R. Si vous rencontrez une latence inattendue lorsque vous utilisez le adaptive mode, consultez le AWS guide de documentation pour le service que vous utilisez.

Détails de mise en œuvre du mode Réessai

Le AWS SDKsutilisez des compartiments à jetons pour décider si une demande doit être réessayée et (dans le cas du mode adaptive nouvelle tentative) à quelle vitesse les demandes doivent être envoyées. Deux compartiments de jetons sont utilisés par le SDK : un compartiment de jetons de nouvelle tentative et un compartiment de jetons de taux de demande.

Voici le pseudocode de haut niveau pour les modes standard et adaptive nouvelle tentative :

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)
  }
}

Vous trouverez ci-dessous des informations supplémentaires sur les composants utilisés dans le pseudocode :

GetSendToken:

Cette étape n'est utilisée qu'en mode adaptive nouvelle tentative. Cette étape permet d'acquérir un jeton à partir du bucket de jetons du taux de demande. Si un jeton n'est pas disponible, il attendra qu'il soit disponible. Des options de configuration sont SDK peut-être disponibles pour échouer à la demande au lieu d'attendre. Les jetons contenus dans le compartiment sont rechargés à un rythme déterminé dynamiquement, en fonction du nombre de réponses de régulation reçues par le client.

SendHTTPRequest:

Cette étape envoie la demande à AWS. La plupart AWS SDKsutilisez une HTTP bibliothèque qui utilise des pools de connexions pour réutiliser une connexion existante lors d'une HTTP demande. En général, les connexions sont réutilisées si une demande a échoué en raison d'erreurs de régulation, mais pas si une demande échoue en raison d'une erreur transitoire.

RequestBookkeeping:

Les jetons sont ajoutés au compartiment de jetons si la demande aboutit. Pour le mode adaptive nouvelle tentative uniquement, le taux de remplissage du compartiment de jetons de taux de demande est mis à jour en fonction du type de réponse reçue.

Retryable:

Cette étape détermine si une réponse peut être réessayée en fonction des éléments suivants :

Les erreurs transitoires (codes d'HTTPétat 400, 408, 500, 502, 503 et 504) et les erreurs de régulation (codes d'HTTPétat 400, 403, 429, 502, 503 et 509) peuvent toutes potentiellement être réessayées. SDKle comportement des nouvelles tentatives est déterminé en combinaison avec les codes d'erreur ou d'autres données du service.

MAX_ATTEMPTS:

Le nombre maximal de tentatives par défaut est défini par le retry_mode paramètre, sauf s'il est remplacé par le max_attempts paramètre.

HasRetryQuota

Cette étape permet d'acquérir un jeton dans le compartiment de jetons Retry. Si le compartiment de jetons de nouvelle tentative est vide, la demande ne sera pas réessayée.

ExponentialBackoff

Dans le cas d'une erreur pouvant être tentée à nouveau, le délai de nouvelle tentative est calculé à l'aide d'une réduction exponentielle tronquée. Ils SDKs utilisent un recul exponentiel binaire tronqué avec instabilité. L'algorithme suivant montre comment la durée de sommeil, en secondes, est définie pour une réponse à une demande i :

seconds_to_sleep_i = min(b*r^i, MAX_BACKOFF)

Dans l'algorithme précédent, les valeurs suivantes s'appliquent :

b = random number within the range of: 0 <= b <= 1

r = 2

MAX_BACKOFF = 20 secondspour la plupartSDKs. Consultez votre SDK guide ou code source spécifique pour obtenir une confirmation.

Compatibilité avec AWS SDKs

Les éléments suivants SDKs prennent en charge les fonctionnalités et les paramètres décrits dans cette rubrique. Toute exception partielle est notée. Tous les paramètres des propriétés JVM du système sont pris en charge par le AWS SDK for Java et le Kit AWS SDK pour Kotlin uniquement.