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

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 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 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 codice deve essere progettato per avere un client per coppia. Region-and-table 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

AWS SDKs Utilizzano i token bucket per decidere se ritentare una richiesta e (nel caso della modalità adaptive retry) con quale rapidità inviare le richieste. L'SDK utilizza due bucket di token: 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. Il tuo SDK potrebbe avere opzioni di configurazione disponibili per fallire 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 SDKs utilizza una libreria HTTP che utilizza pool di connessioni per riutilizzare una connessione esistente quando si effettua una richiesta HTTP. 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 temporaneo.

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 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 tentativi SDK 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 parte SDKs. Consulta la guida SDK o il codice sorgente specifici per avere conferma.

Support by AWS SDKs and tools

Di seguito sono SDKs supportate 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 per Java and the. SDK AWS for Kotlin