Nouvelle tentative

Les appels vers Services AWS peuvent échouer de temps en temps pour des raisons inattendues. Certaines erreurs, telles que le ralentissement (débit dépassé) ou les erreurs transitoires, peuvent réussir si l'appel est retenté. AWS SDK for Java 2.x Il dispose d'un mécanisme intégré pour détecter de telles erreurs et réessayer automatiquement l'appel qui est activé par défaut pour tous les clients.

Cette page décrit comment cela fonctionne, comment configurer les différents modes et adapter le comportement des nouvelles tentatives.

Réessayez les stratégies

Une stratégie de nouvelle tentative est un mécanisme utilisé pour SDK implémenter les nouvelles tentatives. Chaque SDK client dispose d'une stratégie de réessai créée au moment de la création qui ne peut pas être modifiée une fois le client créé.

La stratégie de nouvelle tentative comporte les responsabilités suivantes.

• Classez les exceptions comme réessayables ou non.

• Calculez le délai d'attente suggéré avant la prochaine tentative.

• Gérez un bucket de jetons qui fournit un mécanisme permettant d'arrêter les nouvelles tentatives lorsqu'un pourcentage élevé de demandes échouent et que les nouvelles tentatives échouent.

Note

Avant la publication des stratégies de nouvelle tentative avec la version 2.26.0 duSDK, les politiques de nouvelle tentative fournissaient le mécanisme de nouvelle tentative dans le. SDK La politique de nouvelle tentative API est composée de la RetryPolicyclasse principale du software.amazon.awssdk.core.retry package, tandis que le software.amazon.awssdk.retries package contient les éléments de stratégie API de nouvelle tentative.

La stratégie de nouvelle tentative API a été introduite dans le cadre d' AWS un vaste effort visant à unifier les interfaces et le comportement des principaux composants du. SDKs

SDKPour Java 2.x, trois stratégies de réessai sont intégrées : standard, ancienne et adaptative. Les trois stratégies de nouvelle tentative sont préconfigurées pour réessayer un ensemble d'exceptions réessayables. Parmi les erreurs réessayables, citons les délais d'expiration des sockets, le ralentissement côté service, la simultanéité ou les échecs de verrouillage optimistes, ainsi que les erreurs de service transitoires.

Stratégie de nouvelle tentative standard

La stratégie de nouvelle tentative standard est la RetryStrategy mise en œuvre recommandée pour les cas d'utilisation normaux. Contrairement à la AdaptiveRetryStrategy stratégie standard est généralement utile dans tous les cas d'utilisation de nouvelles tentatives.

Par défaut, la stratégie de nouvelle tentative standard effectue les opérations suivantes.

• Réessaie selon les conditions configurées au moment de la création. Vous pouvez régler cela avecStandardRetryStrategy.Builder#retryOnException.

• Réessaie 2 fois pour un total de 3 tentatives. Vous pouvez régler cela avecStandardRetryStrategy.Builder#maxAttempts(int).

• Pour les exceptions autres que la limitation, il utilise la stratégie de BackoffStrategy#exponentialDelay réduction, avec un délai de base de 100 millisecondes et un délai maximum de 20 secondes. Vous pouvez régler cela avecStandardRetryStrategy.Builder#backoffStrategy.

• Pour les exceptions de limitation, il utilise la stratégie de BackoffStrategy#exponentialDelay réduction, avec un délai de base de 1 seconde et un délai maximum de 20 secondes. Vous pouvez régler cela avecStandardRetryStrategy.Builder#throttlingBackoffStrategy.

• Procède à une coupure de circuit (désactivation des nouvelles tentatives) en cas de défaillances importantes en aval. La première tentative est toujours exécutée, seules les nouvelles tentatives sont désactivées. Ajustez avecStandardRetryStrategy.Builder#circuitBreakerEnabled.

Ancienne stratégie de réessai

L'ancienne stratégie de nouvelle tentative est RetryStrategy réservée aux cas d'utilisation normaux, mais elle est déconseillée au profit de. StandardRetryStrategy Il s'agit de la stratégie de nouvelle tentative par défaut utilisée par les clients lorsque vous ne spécifiez aucune autre stratégie.

Il se caractérise par un traitement différent des exceptions d'étranglement et de non-limitation. Pour les exceptions de limitation, le délai de base pour le backoff est supérieur (500 ms) au délai de base pour les exceptions non limitantes (100 ms), et les exceptions de limitation n'affectent pas l'état du bucket de jetons.

L'expérience de l'utilisation de cette stratégie à grande échelle en interne AWS a montré qu'elle n'est pas particulièrement meilleure que la stratégie de réessai standard. De plus, cela ne protège pas les services en aval contre les tempêtes de nouvelles tentatives et peut entraîner une pénurie de ressources du côté du client.

Par défaut, l'ancienne stratégie de nouvelles tentatives effectue les opérations suivantes.

• Réessaie selon les conditions configurées au moment de la création. Vous pouvez régler cela avecLegacyRetryStrategy.Builder#retryOnException.

• Réessaie 3 fois pour un total de 4 tentatives. Vous pouvez régler cela avecLegacyRetryStrategy.Builder#maxAttempts(int).

• Pour les exceptions autres que la limitation, il utilise la stratégie de BackoffStrategy#exponentialDelay réduction, avec un délai de base de 100 millisecondes et un délai maximum de 20 secondes. Vous pouvez régler cela avec LegacyRetryStrategy.Builder#backoffStrategy.

• Pour les exceptions de limitation, il utilise la stratégie de BackoffStrategy#exponentialDelay réduction, avec un délai de base de 500 millisecondes et un délai maximum de 20 secondes. Vous pouvez régler cela avecLegacyRetryStrategy.Builder#throttlingBackoffStrategy.

• Procède à une coupure de circuit (désactivation des nouvelles tentatives) en cas de défaillances importantes en aval. Une coupure de circuit n'empêche jamais une première tentative réussie. Vous pouvez ajuster ce comportement avecLegacyRetryStrategy.Builder#circuitBreakerEnabled.

• L'état du disjoncteur n'est pas affecté par les exceptions d'étranglement.

Stratégie de nouvelle tentative adaptative

La stratégie de nouvelle tentative adaptative est RetryStrategy destinée aux cas d'utilisation présentant un niveau élevé de contraintes de ressources.

La stratégie de nouvelle tentative adaptative inclut toutes les fonctionnalités de la stratégie standard et ajoute un limiteur de débit côté client qui mesure le taux de demandes limitées par rapport aux demandes non limitées. La stratégie utilise cette mesure pour ralentir les demandes afin de rester dans une bande passante sûre, en évitant idéalement toute erreur de régulation.

Par défaut, la stratégie de nouvelle tentative adaptative effectue les opérations suivantes.

• Réessaie selon les conditions configurées au moment de la création. Vous pouvez régler cela avecAdaptiveRetryStrategy.Builder#retryOnException.

• Réessaie 2 fois pour un total de 3 tentatives. Vous pouvez régler cela avecAdaptiveRetryStrategy.Builder#maxAttempts(int).

• Utilise un délai de ralentissement dynamique basé sur la charge actuelle par rapport à la ressource en aval.

• Interroge le circuit (désactive les nouvelles tentatives) lorsque le nombre de défaillances en aval est élevé. La coupure de circuit peut empêcher une seconde tentative dans les scénarios de panne afin de protéger le service en aval.

Avertissement

La stratégie de nouvelle tentative adaptative suppose que le client travaille sur une seule ressource (par exemple, une table DynamoDB ou un compartiment Amazon S3).

Si vous utilisez un seul client pour plusieurs ressources, les ralentissements ou les pannes associés à une ressource entraînent une latence accrue et des défaillances lorsque le client accède à toutes les autres ressources. Lorsque vous utilisez la stratégie de nouvelle tentative adaptative, nous vous recommandons d'utiliser un seul client pour chaque ressource.

Nous vous recommandons également d'utiliser cette stratégie dans les situations où tous les clients utilisent la stratégie de nouvelle tentative adaptative par rapport à la ressource.

Important

La version 2.26.0 de Java des stratégies de nouvelle tentative SDK inclut la nouvelle RetryMode.ADAPTIVE_V2valeur d'énumération. Le ADAPTIVE_V2 mode corrige une erreur qui n'a pas retardé la première tentative alors que des erreurs de régulation avaient été détectées précédemment.

Avec la version 2.26.0, les utilisateurs obtiennent automatiquement le comportement du ADAPTIVE_V2 mode en le définissant comme s'il s'agissait d'une variable adaptive d'environnement, d'une propriété système ou d'un paramètre de profil. Il n'existe aucune adaptive_v2 valeur pour ces paramètres. Consultez la Spécifiez une stratégie section suivante pour savoir comment définir le mode.

Les utilisateurs peuvent obtenir le comportement précédent en définissant le mode dans le code à l'aide deRetryMode.ADAPTIVE.

Résumé : Comparaison des valeurs par défaut des stratégies de nouvelle tentative

Le tableau suivant indique les valeurs par défaut pour les propriétés de chaque stratégie de nouvelle tentative.

Strategy	Nombre maximum de tentatives	Délai de base pour les erreurs non liées à l'étranglement	Délai de base pour les erreurs d'étranglement	Taille du compartiment de jetons	Coût du jeton par nouvelle tentative sans limitation	Coût du jeton par nouvelle tentative de limitation
Standard	3	100	100	500	5	5
Héritée	4	100	500	500	5	0
Adaptatif	3	100	100	500	5	5

Spécifiez une stratégie

Vous pouvez définir une stratégie pour votre client de service de quatre manières.

Dans le code

Lorsque vous créez un client, vous pouvez configurer une expression lambda avec une stratégie de nouvelle tentative. L'extrait de code suivant configure une stratégie de nouvelle tentative standard qui utilise les valeurs par défaut sur un client de service DynamoDB.

DynamoDbClient client = DynamoDbClient.builder()
        .overrideConfiguration(o -> o.retryStrategy(RetryMode.STANDARD))
        .build();

Vous pouvez spécifier RetryMode.LEGACY ou RetryMode.ADAPTIVE à la place deRetryMode.STANDARD.

En tant que paramètre de profil

Inclure retry_mode en tant que paramètre de profil dans le fichier de AWS configuration partagé. Spécifiez standardlegacy, ou adaptive sous forme de valeur. Lorsqu'il est défini comme paramètre de profil, tous les clients de service créés alors que le profil est actif utilisent la stratégie de nouvelle tentative spécifiée avec des valeurs par défaut. Vous pouvez annuler ce paramètre en configurant une stratégie de nouvelle tentative dans le code, comme indiqué précédemment.

Avec le profil suivant, tous les clients du service utilisent la stratégie de réessai standard.

[profile dev]
region = us-east-2
retry_mode = standard

En tant que propriété JVM du système

Vous pouvez configurer une stratégie de nouvelle tentative pour tous les clients du service, à moins qu'elle ne soit remplacée dans le code, à l'aide de la propriété system. aws.retryMode Spécifiez standardlegacy, ou adaptive sous forme de valeur.

Utilisez le -D commutateur lorsque vous appelez Java, comme indiqué dans la commande suivante.

java -Daws.retryMode=standard ...

Vous pouvez également définir la propriété système dans le code avant de créer un client, comme indiqué dans l'extrait suivant.

public void main(String[] args) {
    // Set the property BEFORE any AWS service clients are created.
    System.setProperty("aws.retryMode", "standard");
    ...
}

Avec une variable d'environnement

Vous pouvez également utiliser la variable d'AWS_RETRY_MODEenvironnement avec une valeur de standardlegacy, ouadaptive. Comme pour un paramètre de profil ou une propriété JVM système, la variable d'environnement configure tous les clients de service avec le mode de nouvelle tentative spécifié, sauf si vous configurez un client dans le code.

La commande suivante définit le mode de nouvelle tentative sur standard la session shell en cours.

export AWS_RETRY_MODE=standard

Personnaliser une stratégie

Vous pouvez personnaliser n'importe quelle stratégie de nouvelle tentative en définissant le nombre maximal de tentatives, la stratégie de temporisation et les exceptions pouvant être réessayées. Vous pouvez personnaliser le moment où vous créez une stratégie de nouvelle tentative ou le moment où vous créez un client en utilisant un générateur de remplacement qui permet d'affiner davantage la stratégie configurée.

Personnalisez le nombre maximum de tentatives

Vous pouvez configurer le nombre maximum de tentatives pendant la construction du client, comme indiqué dans l'instruction suivante. L'instruction suivante personnalise la stratégie de relance par défaut pour le client, avec un maximum de 5 tentatives, soit une première tentative plus 4 tentatives.

DynamoDbClient client = DynamoDbClient.builder()
        .overrideConfiguration(o -> o.retryStrategy(b -> b.maxAttempts(5)))
        .build();

Vous pouvez également créer la stratégie et la fournir au client comme dans l'exemple de code suivant. Le code suivant remplace les 3 tentatives maximales standard par 10 et configure un client DynamoDB avec la stratégie personnalisée.

StandardRetryStrategy strategy = AwsRetryStrategy.standardRetryStrategy()
         .toBuilder()
         .maxAttempts(10)
         .build();
DynamoDbClient client = DynamoDbClient.builder()
        .overrideConfiguration(o -> o.retryStrategy(strategy))
        .build();       

Avertissement

Nous vous recommandons de configurer chaque client avec une RetryStrategy instance unique. Si une RetryStrategy instance est partagée, les échecs d'un client peuvent affecter le comportement de nouvelle tentative de l'autre.

Vous pouvez également définir le nombre maximum de tentatives pour tous les clients en utilisant des paramètres externes plutôt que du code. Vous configurez ce paramètre comme décrit dans la Spécifiez une stratégie section.

Personnaliser les exceptions réessayables

Vous pouvez configurer des exceptions supplémentaires qui déclenchent des suppressions lors de la construction du client. Cette personnalisation est prévue pour les cas extrêmes dans lesquels des exceptions non incluses dans l'ensemble par défaut d'exceptions réessayables sont émises.

L'extrait de code suivant montre les méthodes que vous utilisez pour personnaliser les exceptions de nouvelle tentative : et. retryOnException retryOnExceptionOrCause La retryOnExceptionOrCause méthode ajoute une exception réessayable si elle SDK lance l'exception directe ou si l'exception est encapsulée.

DynamoDbClient client = DynamoDbClient.builder()
        .overrideConfiguration(o -> o.retryStrategy(
                 b -> b.retryOnException(EdgeCaseException.class)
                       .retryOnExceptionOrCause(WrappedEdgeCaseException.class)))
        .build();

Personnalisez la stratégie de backoff

Vous pouvez élaborer la stratégie de backoff et la fournir au client.

Le code suivant crée un BackoffStrategy qui remplace la stratégie de réduction du délai exponentiel par défaut de la stratégie standard.

BackoffStrategy backoffStrategy = 
        BackoffStrategy.exponentialDelay(Duration.ofMillis(150),  // The base delay.
                                         Duration.ofSeconds(15)); // The maximum delay.
DynamoDbClient client = DynamoDbClient.builder()
        .overrideConfiguration(o -> o.retryStrategy(
                b -> b.backoffStrategy(backoffStrategy)))
        .build();

Migration depuis RetryPolicy vers RetryStrategy

RetryPolicy(la politique de nouvelle tentativeAPI) sera prise en charge dans un futur proche. Si vous utilisez actuellement une instance de RetryPolicy pour configurer votre client, tout fonctionnera comme avant. Dans les coulisses, Java l'SDKadapte à unRetryStrategy. Les nouvelles interfaces de stratégie de nouvelle tentative fournissent les mêmes fonctionnalités que a, RetryPolicy mais elles sont créées et configurées différemment.