Réessayez avec le schéma de désactivation

Intention

Le modèle de nouvelle tentative avec interruption améliore la stabilité de l'application en réessayant de manière transparente les opérations qui échouent en raison d'erreurs transitoires.

Motivation

Dans les architectures distribuées, les erreurs transitoires peuvent être causées par une limitation des services, une perte temporaire de connectivité réseau ou une indisponibilité temporaire du service. Réessayer automatiquement les opérations qui échouent en raison de ces erreurs transitoires améliore l'expérience utilisateur et la résilience des applications. Toutefois, des tentatives fréquentes peuvent surcharger la bande passante du réseau et provoquer des conflits. L'interruption exponentielle est une technique dans laquelle les opérations sont relancées en augmentant les temps d'attente pour un nombre spécifié de tentatives.

Applicabilité

Utilisez le schéma de réessai avec retour en arrière dans les cas suivants :

• Vos services limitent fréquemment la demande pour éviter toute surcharge, ce qui entraîne une429 Trop de demandesexception au processus d'appel.

• Le réseau joue un rôle invisible dans les architectures distribuées, et les problèmes temporaires du réseau entraînent des défaillances.

• Le service appelé est temporairement indisponible, ce qui entraîne des défaillances. Les tentatives fréquentes peuvent entraîner une dégradation du service à moins que vous n'introduisiez un délai d'attente en utilisant ce modèle.

Enjeux et considérations

• Idempotence: Si plusieurs appels à la méthode ont le même effet qu'un seul appel sur l'état du système, l'opération est considérée comme idempotente. Les opérations doivent être idempotentes lorsque vous utilisez le schéma de nouvelle tentative avec recul. Dans le cas contraire, des mises à jour partielles risquent d'altérer l'état du système.

• Bande passante réseau: Une dégradation du service peut se produire si trop de nouvelles tentatives occupent la bande passante du réseau, ce qui ralentit les temps de réponse.

• Scénarios d'échec rapide: Pour les erreurs non transitoires, si vous pouvez déterminer la cause de la panne, il est plus efficace de tomber en panne rapidement en utilisant le schéma des disjoncteurs.

• Taux de retrait: L'introduction d'une interruption exponentielle peut avoir un impact sur le délai d'expiration du service, ce qui allonge les délais d'attente pour l'utilisateur final.

Mise en œuvre

Architecture de haut niveau

Le schéma suivant montre comment le service A peut réessayer d'appeler le service B jusqu'à ce qu'une réponse positive soit renvoyée. Si le service B ne renvoie pas de réponse satisfaisante après quelques essais, le service A peut arrêter de réessayer et renvoyer un message d'échec à son appelant.

Mise en œuvre en utilisantAWSservices

Le schéma suivant montre un flux de travail de traitement des tickets sur une plateforme de support client. Les tickets provenant de clients mécontents sont accélérés grâce à l'augmentation automatique de la priorité des tickets. LeTicket infoLa fonction Lambda extrait les détails du ticket et appelleGet sentimentFonction Lambda. LeGet sentimentLa fonction Lambda vérifie les sentiments des clients en transmettant la description àAmazon Comprehend(non illustré).

Si l'appel auGet sentimentLa fonction Lambda échoue, le flux de travail réessaie l'opération trois fois.AWS Step Functionspermet un recul exponentiel en vous permettant de configurer la valeur d'intervalle.

Dans cet exemple, un maximum de trois tentatives sont configurées avec un multiplicateur d'augmentation de 1,5 seconde. Si la première tentative a lieu au bout de 3 secondes, la deuxième au bout de 3 x 1,5 seconde = 4,5 secondes et la troisième au bout de 4,5 x 1,5 seconde = 6,75 secondes. Si la troisième tentative échoue, le flux de travail échoue. La logique de sauvegarde ne nécessite aucun code personnalisé. Elle est fournie sous forme de configuration parAWS Step Functions.

Exemple de code

Le code suivant montre l'implémentation du modèle de nouvelle tentative avec backoff.

public async Task DoRetriesWithBackOff()
  {
     int retries = 0;
     bool retry;
     do
     {
       //Sample object for sending parameters
       var parameterObj = new InputParameter { SimulateTimeout = "false" };
       var content = new StringContent(JsonConvert.SerializeObject(parameterObj), 
                                System.Text.Encoding.UTF8, "application/json");
       var waitInMilliseconds = Convert.ToInt32((Math.Pow(2, retries) - 1) * 100);
       System.Threading.Thread.Sleep(waitInMilliseconds);
       var response =  await _client.PostAsync(_baseURL, content);
       switch (response.StatusCode)
       {
         //Success
         case HttpStatusCode.OK:
           retry = false;
           Console.WriteLine(response.Content.ReadAsStringAsync().Result);
           break;
         //Throttling, timeouts 
         case HttpStatusCode.TooManyRequests:
         case HttpStatusCode.GatewayTimeout:
           retry = true;
           break;
         //Some other error occured, so stop calling the API
         default:
           retry = false;
           break;
       }
       retries++;
     } while (retry && retries < MAX_RETRIES);
  }

GitHubréférentiel

Pour une implémentation complète de l'exemple d'architecture pour ce modèle, consultez leGitHubdépôt surhttps://github.com/aws-samples/retry-with-backoff.

Contenu connexe

• Délais d'attente, nouvelles tentatives et retour en arrière avec instabilité(Bibliothèque Amazon Builders)