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 il SDKs tentativo di ripristino degli errori risultanti dalle richieste effettuate a Servizi AWS.

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

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 utilizza Regione AWS oltre all'accesso alla tabella per le richieste di accelerazione. Ciò significa che una tabella a cui accede il tuo 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 le specifiche AWS guida alla documentazione relativa al servizio in uso.

Dettagli sull'implementazione della modalità Riprova

Il AWS SDKsutilizza i token bucket per decidere se ritentare una richiesta e (nel caso della modalità adaptive retry) con quale rapidità inviare le richieste. Due bucket di token vengono utilizzati daSDK: un bucket di token retry e un bucket di token di frequenza di richiesta.

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:

Questo passaggio viene utilizzato solo in adaptive modalità riprova. Questo passaggio acquisisce un token dal bucket di token del tasso di richiesta. Se un token non è disponibile, aspetterà che ne diventi disponibile uno. È SDK possibile che siano disponibili opzioni di configurazione per non riuscire a completare la richiesta anziché attendere. I token presenti nel bucket vengono ricaricati a una velocità determinata dinamicamente, in base al numero di risposte di limitazione ricevute dal client.

SendHTTPRequest:

Questo passaggio invia la richiesta a AWS. La maggior parte AWS SDKsutilizza una HTTP libreria che utilizza i pool di connessioni per riutilizzare una connessione esistente quando si effettua una HTTP richiesta. In genere, le connessioni vengono riutilizzate se una richiesta non è riuscita a causa di errori di limitazione, ma non se una richiesta fallisce a causa di un errore transitorio.

RequestBookkeeping:

I token vengono aggiunti al token bucket se la richiesta ha esito positivo. Solo per la modalità adaptive riprova, la frequenza di riempimento del bucket di token del tasso di richiesta viene aggiornata in base al tipo di risposta ricevuta.

Retryable:

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

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

MAX_ATTEMPTS:

Il numero massimo di tentativi predefinito è impostato dall'retry_modeimpostazione, a meno che l'impostazione non venga sovrascritta dall'impostazione. max_attempts

HasRetryQuota

Questo passaggio acquisisce un token dal bucket retry token. Se il bucket del token Retry è vuoto, la richiesta non verrà ritentata.

ExponentialBackoff

Per un errore che può essere ritentato, il ritardo tra i tentativi viene calcolato utilizzando un backoff esponenziale troncato. Viene SDKs utilizzato 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 parteSDKs. Consulta la tua SDK guida o il codice sorgente specifici per conferma.

Compatibilità con AWS SDKs

Di seguito sono SDKs supportate le funzionalità e le impostazioni descritte in questo argomento. Vengono annotate eventuali eccezioni parziali. Tutte le impostazioni delle proprietà di JVM sistema sono supportate da AWS SDK for Java e il SDK AWS for Kotlin solo.