Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
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 info
La funzione Lambda estrae i dettagli del ticket e chiama ilGet sentiment
Funzione lambda. LaGet sentiment
La funzione Lambda verifica le opinioni dei clienti passando la descrizione aAmazon Comprehend
Se la chiamata alGet sentiment
La 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)