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à.
# Nuovo tentativo con schema di backoff
## Intento
Il pattern Retry with Backoff migliora la stabilità dell'applicazione riprovando in modo trasparente le operazioni che falliscono a causa di errori temporanei.
## 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. Riprovare automaticamente le 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 conflitti. Il backoff esponenziale è una tecnica in cui le operazioni vengono ritentate aumentando i tempi di attesa per un determinato numero di tentativi.
## Applicabilità
Utilizza lo schema Retry with backoff quando:
+ I tuoi servizi spesso limitano la richiesta per evitare il sovraccarico, con conseguente eccezione *429 Too many requests* al processo di chiamata.
+ La rete è un elemento invisibile delle architetture distribuite e i problemi di rete temporanei provocano guasti.
+ Il servizio chiamato è temporaneamente non disponibile, con conseguenti errori. I tentativi frequenti possono causare un peggioramento 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 viene considerata idempotente**. Le operazioni devono essere idempotenti quando si utilizza il pattern retry with backoff. In caso contrario, gli aggiornamenti parziali potrebbero danneggiare lo stato del sistema.
+ **Larghezza di banda di rete**: se troppi tentativi occupano la larghezza di banda della rete può verificarsi un peggioramento del servizio, con conseguenti tempi di risposta lenti.
+ **Scenari di errore rapido**: per gli errori non transitori, se è possibile determinare la causa dell'errore, è più efficiente fallire rapidamente utilizzando lo schema degli interruttori automatici.
+ **Frequenza 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ò ritentare 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 i tentativi e restituire un errore al chiamante.
![\[Architettura di alto livello per riprovare con pattern di backoff\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/cloud-design-patterns/images/retry-backoff-1.png)
### Implementazione tramite servizi AWS
Il diagramma seguente mostra un flusso di lavoro di elaborazione dei ticket su una piattaforma di assistenza clienti. I ticket provenienti da clienti insoddisfatti vengono velocizzati aumentando automaticamente la priorità dei ticket. La funzione `Ticket info` Lambda estrae i dettagli del ticket e richiama la funzione `Get sentiment` Lambda. [La funzione `Get sentiment` Lambda verifica le opinioni dei clienti passando la descrizione ad Amazon Comprehend (non mostrata).](https://aws.amazon.com/comprehend/)
Se la chiamata alla funzione `Get sentiment` Lambda fallisce, il flusso di lavoro riprova l'operazione tre volte. AWS Step Functions consente il backoff esponenziale consentendo di configurare il valore di backoff.
In questo esempio, vengono configurati un massimo di tre tentativi con un moltiplicatore di aumento di 1,5 secondi. Se il primo tentativo si verifica 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 ha esito negativo, il flusso di lavoro ha esito negativo. La logica di backoff non richiede alcun codice personalizzato, viene fornita come configurazione da. AWS Step Functions
![\[Riprova con uno schema di backoff con servizi AWS\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/cloud-design-patterns/images/retry-backoff-2.png)
### 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);
}
```
### GitHub deposito
Per un'implementazione completa dell'architettura di esempio per questo modello, consulta il GitHub repository all'indirizzo. [https://github.com/aws-samples/retry-with-backoff](https://github.com/aws-samples/retry-with-backoff)
## Contenuti correlati
+ [Timeout, nuovi tentativi e backoff con jitter (Amazon Builders'](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) Library)