Riprova con schema di backoff

Intento

Lo schema Riprova con backoff migliora la stabilità dell'applicazione riprovando in modo trasparente le operazioni che hanno esito negativo a causa di errori transitori.

Motivazione

Nelle architetture distribuite, gli errori transitori possono essere causati dalla limitazione del servizio, dalla perdita temporanea della connettività di rete o dalla temporanea indisponibilità del servizio. La ripetizione automatica delle operazioni che falliscono a causa di questi errori transitori migliora l'esperienza utente e la resilienza delle applicazioni. Tuttavia, i tentativi frequenti possono sovraccaricare la larghezza di banda della rete e causare contese. Il backoff esponenziale è una tecnica in cui le operazioni vengono ripetute aumentando i tempi di attesa per un numero specificato di tentativi.

Applicabilità

Usa lo schema Riprova con backoff quando:

• I tuoi servizi spesso limitano la richiesta per evitare il sovraccarico, con conseguente429 Troppe richiesteeccezione al processo di chiamata.

• La rete partecipa in modo invisibile alle architetture distribuite e problemi temporanei di rete provocano guasti.

• Il servizio richiamato è temporaneamente non disponibile, con conseguenti errori. I tentativi frequenti possono causare il degrado del servizio a meno che non si introduca un timeout di backoff utilizzando questo schema.

Problemi e considerazioni

• Idempotenza: se più chiamate al metodo hanno lo stesso effetto di una singola chiamata sullo stato del sistema, l'operazione è considerata idempotente. Le operazioni devono essere idempotenti quando si utilizza lo schema Riprova con backoff. In caso contrario, gli aggiornamenti parziali potrebbero danneggiare lo stato del sistema.

• Larghezza di banda di rete: il degrado del servizio può verificarsi se troppi tentativi occupano la larghezza di banda della rete, con conseguenti tempi di risposta lenti.

• Scenari di fallimento rapido: Per gli errori non transitori, se è possibile determinare la causa del guasto, è più efficiente eseguire un guasto rapido utilizzando lo schema dell'interruttore automatico.

• Tasso di backoff: L'introduzione del backoff esponenziale può avere un impatto sul timeout del servizio, con conseguenti tempi di attesa più lunghi per l'utente finale.

Implementazione

Architettura di alto livello

Il diagramma seguente illustra come il servizio A può riprovare le chiamate al servizio B fino a quando non viene restituita una risposta corretta. Se il servizio B non restituisce una risposta corretta dopo alcuni tentativi, il servizio A può interrompere il tentativo e restituire un errore al chiamante.

Implementazione utilizzandoAWSservizi

Il diagramma seguente mostra un flusso di lavoro di elaborazione dei ticket su una piattaforma di assistenza clienti. I ticket dei clienti insoddisfatti vengono accelerati aumentando automaticamente la priorità dei biglietti. LaTicket infoLa funzione Lambda estrae i dettagli del ticket e chiama ilGet sentimentFunzione lambda. LaGet sentimentLa funzione Lambda verifica le opinioni dei clienti passando la descrizione aAmazon Comprehend(non mostrato).

Se la chiamata alGet sentimentLa funzione Lambda fallisce, il flusso di lavoro riprova l'operazione tre volte.AWS Step Functionsconsente un backoff esponenziale consentendoti di configurare il valore di backoff.

In questo esempio, vengono configurati un massimo di tre tentativi con un moltiplicatore di incremento di 1,5 secondi. Se il primo tentativo avviene dopo 3 secondi, il secondo dopo 3 x 1,5 secondi = 4,5 secondi e il terzo dopo 4,5 x 1,5 secondi = 6,75 secondi. Se il terzo tentativo non va a buon fine, il flusso di lavoro ha esito negativo. La logica di backoff non richiede alcun codice personalizzato: viene fornita come configurazione daAWS Step Functions.

Codice di esempio

Il codice seguente mostra l'implementazione del pattern retry with 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);
  }

GitHubmagazzino

Per un'implementazione completa dell'architettura di esempio per questo modello, vedereGitHubrepository pressohttps://github.com/aws-samples/retry-with-backoff.

Contenuti correlati

• Timeout, nuovi tentativi e retromarcia con jitter(Libreria di Amazon Builders)