Jitter nei retry

Il jitter introduce casualità nell’attesa prima di una nuova chiamata. Distribuisce nel tempo i tentativi di più client. È particolarmente utile quando molti client rilevano lo stesso guasto nello stesso momento: una pausa identica può limitarsi a spostare il prossimo picco di carico.

Tre client, attese diverse

In un esempio fittizio, tre client possono scegliere ciascuno un’attesa casuale in una finestra di 0–2 s prima del tentativo successivo. Attendono, per esempio, 0.4 s, 1.1 s e 1.7 s. Questi valori illustrano la distribuzione; non sono una configurazione consigliata. I tentativi possono ancora coincidere anche con il jitter.

La strategia dei nuovi tentativi continua a stabilire quali errori giustificano un altro tentativo, quanti ne sono consentiti e quando scade il tempo complessivo. Vanno rispettate le indicazioni del sistema destinatario sui tempi di attesa. Con il backoff esponenziale, l’intervallo di attesa cresce di norma con i tentativi successivi fino a un limite configurato; il jitter varia la pausa effettiva secondo la regola utilizzata.

La casualità non rende sicura la ripetizione di un’operazione. Una risposta persa può nascondere una scrittura già completata. Prima di riprovare, l’integrazione ha quindi bisogno di una regola di ripetizione sicura, come l’idempotenza o la verifica dell’esito.

Fonti

• AWS Builders’ Library: Timeouts, retries, and backoff with jitter

• AWS Architecture Blog: Exponential Backoff And Jitter