# REL05-BP03 Controllo e limitazione delle chiamate di ripetizione
Utilizza il backoff esponenziale per eseguire nuovi tentativi dopo intervalli progressivamente più lunghi. Introduci il jitter per randomizzare gli intervalli di ripetizione e limitare il numero massimo di tentativi.
I componenti tipici di un sistema software distribuito includono server, sistemi di bilanciamento del carico, database e server DNS. Durante il funzionamento, e sempre soggetti ad anomalie, uno qualsiasi tra questi componenti può iniziare a generare errori. La tecnica predefinita per gestire gli errori consiste nell'implementare nuovi tentativi lato client. Questa tecnica aumenta l'affidabilità e la disponibilità dell'applicazione. Tuttavia, su vasta scala, e se i client tentano di riprovare l'operazione fallita non appena si verifica un errore, la rete può diventare rapidamente satura di richieste nuove e riproposte, ognuna delle quali compete per la larghezza di banda della rete. Ciò può causare una *tempesta di ripetizione dei tentativi,* che ridurrà la disponibilità del servizio. Questo modello potrebbe continuare finché non si verifica un errore completo del sistema.
Per evitare tali scenari, è necessario utilizzare gli algoritmi di backoff come il *backoff esponenziale* comune. Gli algoritmi di backoff esponenziale riducono gradualmente la velocità con cui vengono eseguiti i nuovi tentativi, evitando così la congestione della rete.
Molti SDK e librerie software, inclusi quelli di AWS, implementano una versione di questi algoritmi. Tuttavia, **non dare mai per scontato che esista un algoritmo di backoff: esegui sempre test e verificane la presenza.**
Il backoff semplice da solo non è sufficiente perché nei sistemi distribuiti tutti i client possono eseguire simultaneamente il backoff, creando cluster di chiamate ripetute. Nel suo post del blog [Exponential Backoff and Jitter (Jitter e backoff esponenziale) ](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-italics%0djitter/), spiega come modificare la funzione wait() nel backoff esponenziale per evitare cluster di chiamate riproposte. La soluzione consiste nell'aggiungere *jitter* nella funzione wait(). Per evitare di eseguire nuovi tentativi per troppo tempo, le implementazioni dovrebbero limitare il backoff a un valore massimo.
Infine, è importante configurare un *numero massimo di tentativi* o di tempo trascorso, dopo il quale i nuovi tentativi semplicemente falliranno. Gli SDK AWS lo implementano per impostazione predefinita e può essere configurato. Per i servizi di livello inferiore, un limite massimo di tentativi di risposta pari a zero o a uno può limitare il rischio ed essere comunque efficace in quanto i tentativi di risposta sono delegati ai servizi di livello superiore.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Controlla e limita le chiamate riproposte. Utilizza il backoff esponenziale per eseguire nuovi tentativi dopo intervalli progressivamente più lunghi. Introduci il jitter per randomizzare gli intervalli di ripetizione e limitare il numero massimo di tentativi.
+ [Ripetizione dei tentativi in caso di errore e backoff esponenziale in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ Gli SDK di Amazon implementano i nuovi tentativi e il backoff esponenziale per impostazione predefinita. Potrai implementare una logica similare nel tuo livello di dipendenze quando effettui chiamate ai tuoi servizi dipendenti. Potrai decidere quali sono i timeout e quando cessare i tentativi in base al tuo caso d'uso.
## Risorse
**Documenti correlati:**
+ [Amazon API Gateway: throttling delle richieste API per migliorare le prestazioni ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Ripetizione dei tentativi in caso di errore e backoff esponenziale in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [The Amazon Builders' Library: Evitare il fallback nei sistemi distribuiti](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [The Amazon Builders' Library: Evitare insormontabili backlog di code](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [The Amazon Builders' Library: Sfide e strategie del caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [The Amazon Builders' Library: Timeout, nuovi tentativi e backoff con jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Video correlati:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Presentazione della libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)