Comportamento di ripetizione - AWS SDK e strumenti

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à.

Comportamento di ripetizione

Il comportamento Riprova include le impostazioni relative al modo in cui gli SDK tentano di ripristinare gli errori derivanti dalle richieste effettuate a. Servizi AWS

Configura questa funzionalità utilizzando quanto segue:

max_attempts- impostazione dei AWS config file condivisi
AWS_MAX_ATTEMPTS- variabile d'ambiente
aws.maxAttempts- Proprietà del sistema JVM: solo Java/Kotlin

Speciifica il numero massimo di tentativi da effettuare su una richiesta.

Valore predefinito: se questo valore non è specificato, il valore predefinito dipende dal valore dell'retry_modeimpostazione:

  • Se lo retry_mode èlegacy: utilizza un valore predefinito specifico per il tuo SDK (consulta la guida SDK specifica o la base di codice dell'SDK per max_attempts i valori predefiniti).

  • Se lo retry_mode èstandard: effettua tre tentativi.

  • Se lo retry_mode èadaptive: effettua tre tentativi.

Valori validi: numero maggiore di 0.

retry_mode- impostazione condivisa AWS config dei file
AWS_RETRY_MODE- variabile d'ambiente
aws.retryMode- Proprietà del sistema JVM: solo Java/Kotlin

Specifica in che modo l'SDK o lo strumento di sviluppo tenta di riprovare.

Valore predefinito: legacy è la strategia di ripetizione dei tentativi predefinita.

Valori validi:

  • legacy— Specifico per il tuo SDK (consulta la tua guida SDK specifica o la base di codice dell'SDK).

  • standard— Il set standard di regole di riprova tra gli SDK. AWS Questa modalità include un set standard di errori che vengono ripetuti e il supporto per le quote di tentativi. Il numero massimo predefinito di tentativi con questa modalità è tre, a meno che non max_attempts sia configurata in modo esplicito.

  • adaptive— Una modalità sperimentale di ripetizione che include le funzionalità della modalità standard ma include la limitazione automatica sul lato client. Poiché questa modalità è sperimentale, potrebbe modificare il comportamento in futuro.

Scelta tra le standard modalità e adaptive riprova

Ti consigliamo di utilizzare la modalità standard Riprova a meno che tu non sia sicuro che il tuo utilizzo sia più adatto. adaptive

Nota

La adaptive modalità presuppone che stiate raggruppando i client in base all'ambito in cui il servizio di backend può limitare le richieste. Se non lo fai, le limitazioni di una risorsa potrebbero ritardare le richieste di una risorsa non correlata se utilizzi lo stesso client per entrambe le risorse.

Standard Adattabile
Casi d'uso delle applicazioni: tutti. Casi d'uso dell'applicazione:
  1. Non sensibile alla latenza.

  2. Il client accede solo a una singola risorsa oppure state fornendo la logica per raggruppare i client separatamente in base alla risorsa di servizio a cui si accede.

Supporta l'interruzione del circuito per impedire che l'SDK riprovi durante le interruzioni. Supporta l'interruzione del circuito per impedire all'SDK di riprovare durante le interruzioni.
Utilizza un backoff esponenziale con jitterato in caso di guasti. Utilizza durate di backoff dinamiche per cercare di ridurre al minimo il numero di richieste non riuscite, in cambio del potenziale aumento della latenza.
Non ritarda mai il primo tentativo di richiesta, ma solo i tentativi successivi. Può rallentare o ritardare il tentativo di richiesta iniziale.

Se si sceglie di utilizzare la adaptive modalità, l'applicazione deve creare client progettati in base a ciascuna risorsa che potrebbe essere limitata. Una risorsa, in questo caso, è ottimizzata in modo più preciso e non si limita a pensare a ciascuna di esse. Servizio AWS Servizi AWS possono avere dimensioni aggiuntive che utilizzano per limitare le richieste. Usiamo il servizio Amazon DynamoDB come esempio. DynamoDB Regione AWS utilizza inoltre la tabella a cui si accede per limitare le richieste. Ciò significa che una tabella a cui accede il codice potrebbe essere limitata più di altre. Se il codice utilizza lo stesso client per accedere a tutte le tabelle e le richieste a una di tali tabelle sono limitate, la modalità di riprova adattiva ridurrà la frequenza di richieste per tutte le tabelle. Il tuo codice dovrebbe essere progettato per avere un client per egion-and-table coppia R. Se riscontri una latenza inaspettata durante l'utilizzo della adaptive modalità, consulta la guida alla AWS documentazione specifica per il servizio che stai utilizzando.

Dettagli sull'implementazione della modalità Riprova

Di seguito è riportato lo pseudocodice di alto livello per entrambe le modalità e retry: standard adaptive

MakeSDKRequest() { attempts = 0 loop { GetSendToken() response = SendHTTPRequest() RequestBookkeeping(response) if not Retryable(response) return response attempts += 1 if attempts >= MAX_ATTEMPTS: return response if not HasRetryQuota(response) return response delay = ExponentialBackoff(attempts) sleep(delay) } }

Di seguito sono riportati ulteriori dettagli sui componenti utilizzati nello pseudocodice:

GetSendToken:

I token bucket vengono utilizzati solo in modalità riprova. adaptive I token bucket impongono una frequenza massima di richieste richiedendo la disponibilità di un token per avviare una richiesta. Il client SDK è configurabile per fallire rapidamente la richiesta o bloccarla finché non diventa disponibile un token.

Client Side Rate Limiting è un algoritmo che inizialmente consente di effettuare richieste in qualsiasi momento, fino al limite consentito dal token. Tuttavia, dopo che viene rilevata una risposta limitata, il client rate-of-request viene limitato di conseguenza. La soglia di token viene inoltre aumentata di conseguenza se vengono ricevute risposte positive.

Grazie alla limitazione adattiva della velocità, gli SDK possono rallentare la velocità di invio delle richieste per soddisfare meglio la capacità di. Servizi AWS

SendHTTPRequest:

La maggior parte degli AWS SDK utilizza una libreria HTTP che utilizza pool di connessioni in modo da poter riutilizzare una connessione esistente quando si effettua una richiesta HTTP. In genere, le connessioni vengono riutilizzate quando si riprovano le richieste a causa di errori di limitazione. Le richieste non vengono riutilizzate quando si riprova a causa di errori temporanei.

RequestBookkeeping:

La quota di tentativi deve essere aggiornata se la richiesta ha esito positivo. Solo per la modalità adaptive riprova, la variabile di stato maxsendrate viene aggiornata in base al tipo di risposta ricevuta.

Retryable:

Questo passaggio determina se una risposta può essere ritentata in base a quanto segue:

  • Codice di stato HTTP .

  • Il codice di errore restituito dal servizio.

  • Errori di connessione, definiti come qualsiasi errore ricevuto dall'SDK in cui non viene ricevuta una risposta HTTP dal servizio.

Gli errori transitori (codici di stato HTTP 400, 408, 500, 502, 503 e 504) e gli errori di limitazione (codici di stato HTTP 400, 403, 429, 502, 503 e 509) possono essere tutti potenzialmente ritentati. Il comportamento dei nuovi tentativi dell'SDK viene determinato in combinazione con codici di errore o altri dati del servizio.

MAX_ATTEMPTS:

Specificato dall'impostazione del config file o dalla variabile di ambiente.

HasRetryQuota

Questo passaggio limita le richieste di nuovi tentativi richiedendo che un token sia disponibile nel bucket delle quote di tentativi. I gruppi di quote per nuovi tentativi sono un meccanismo per impedire nuovi tentativi che difficilmente avranno successo. Queste quote dipendono dall'SDK, spesso dipendono dal client e talvolta dipendono anche dagli endpoint del servizio. I token di quota di tentativi disponibili vengono rimossi quando le richieste hanno esito negativo per vari motivi e ripristinati quando hanno esito positivo. Quando non rimangono token, il ciclo di ripetizione dei tentativi viene chiuso.

ExponentialBackoff

Per un errore che può essere riprovato, il ritardo tra i tentativi viene calcolato utilizzando un backoff esponenziale troncato. Gli SDK utilizzano un backoff esponenziale binario troncato con jitter. L'algoritmo seguente mostra come viene definita la quantità di tempo per dormire, in secondi, per una risposta a una richiesta: i

seconds_to_sleep_i = min(b*r^i, MAX_BACKOFF)

Nell'algoritmo precedente, si applicano i seguenti valori:

b = random number within the range of: 0 <= b <= 1

r = 2

MAX_BACKOFF = 20 secondsper la maggior parte degli SDK. Per conferma, consulta la guida SDK o il codice sorgente specifici.

Compatibilità con AWS gli SDK

I seguenti SDK supportano le funzionalità e le impostazioni descritte in questo argomento. Vengono annotate eventuali eccezioni parziali. Tutte le impostazioni delle proprietà del sistema JVM sono supportate solo da AWS SDK for Java and the. SDK AWS for Kotlin

SDK Supportato Note o ulteriori informazioni
AWS CLI v2
SDK per C++
SDK per Go V2 (1.x)
SDK per Go 1.x (V1) No
SDK per Java 2.x
SDK per Java 1.x Proprietà del sistema JVM: usa com.amazonaws.sdk.maxAttempts invece diaws.maxAttempts; usa invece di. com.amazonaws.sdk.retryMode aws.retryMode
SDK per 3.x JavaScript
SDK per 2.x JavaScript No Supporta un numero massimo di tentativi, un backoff esponenziale con jitter e un'opzione per un metodo personalizzato per il backoff dei tentativi.
SDK per Kotlin
SDK per.NET 3.x
SDK per PHP 3.x
SDK per Python (Boto3)
SDK per Ruby 3.x
SDK per Rust
Strumenti per PowerShell