Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Comportamiento de los reintentos

El comportamiento de SDKs reintento incluye la configuración relativa a la forma en que se intenta recuperarse de los errores resultantes de las solicitudes realizadas a Servicios de AWS.

Elegir entre los modos standard y adaptive volver a intentarlo

Le recomendamos que utilice el modo de standard reintento a menos que esté seguro de que su uso es el más adecuado. adaptive

Si opta por utilizar adaptive el modo, la aplicación debe crear clientes diseñados en función de cada recurso que pueda estar limitado. Un recurso, en este caso, está más ajustado que solo pensar en cada uno Servicio de AWS. Servicios de AWS pueden tener dimensiones adicionales que utilizan para limitar las solicitudes. Usemos el servicio Amazon DynamoDB como ejemplo. DynamoDB utiliza Región de AWS además de la tabla a la que se accede para acelerar las solicitudes. Esto significa que una tabla a la que está accediendo tu código podría estar más restringida que otras. Si el código utilizaba el mismo cliente para acceder a todas las tablas y las solicitudes a una de esas tablas están restringidas, el modo de reintento adaptativo reducirá la tasa de solicitudes de todas las tablas. Su código debe diseñarse para tener un cliente por egion-and-table par R. Si experimentas una latencia inesperada al usar adaptive el modo, consulta la sección específica AWS guía de documentación del servicio que está utilizando.

Detalles de implementación del modo de reintento

La AWS SDKsutilice cubos de fichas para decidir si se debe volver a intentar una solicitud y (en el caso del modo de adaptive reintento) con qué rapidez se deben enviar las solicitudes. El grupo utiliza dos grupos de fichasSDK: un grupo de fichas de reintentos y un grupo de fichas de tasa de solicitudes.

A continuación se muestra el pseudocódigo de alto nivel para ambos modos de reintento standard y 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)
  }
}

A continuación se muestran más detalles sobre los componentes utilizados en el pseudocódigo:

GetSendToken:

Este paso solo se utiliza en el modo de reintento. adaptive Este paso adquiere un token del grupo de tokens de tasa de solicitud. Si un token no está disponible, esperará a que esté disponible. SDKEs posible que tengas opciones de configuración disponibles para rechazar la solicitud en lugar de esperar. Los tokens del depósito se rellenan a un ritmo que se determina de forma dinámica, en función del número de respuestas restrictivas que reciba el cliente.

SendHTTPRequest:

En este paso, se envía la solicitud a AWS. La mayoría AWS SDKsutilizan una HTTP biblioteca que utilice grupos de conexiones para reutilizar una conexión existente al realizar una HTTP solicitud. Por lo general, las conexiones se reutilizan si una solicitud falla debido a errores de limitación, pero no si la solicitud falla debido a un error transitorio.

RequestBookkeeping:

Los tokens se añaden al depósito de fichas si la solicitud se realiza correctamente. Solo en el modo de adaptive reintento, la tasa de llenado del depósito de fichas de tasa de solicitudes se actualiza en función del tipo de respuesta recibida.

Retryable:

Este paso determina si se puede volver a intentar una respuesta en función de lo siguiente:

Los errores transitorios (códigos de HTTP estado 400, 408, 500, 502, 503 y 504) y los errores de regulación (códigos de HTTP estado 400, 403, 429, 502, 503 y 509) pueden volver a intentarse. SDKEl comportamiento de los reintentos se determina en combinación con los códigos de error u otros datos del servicio.

MAX_ATTEMPTS:

El número máximo de intentos predeterminado lo establece la retry_mode configuración, a menos que la configuración lo anule. max_attempts

HasRetryQuota

En este paso, se obtiene un token del grupo de reintentos. Si el depósito de fichas de reintento está vacío, no se volverá a intentar la solicitud.

ExponentialBackoff

En el caso de un error que se pueda volver a intentar, el retraso del reintento se calcula mediante un retroceso exponencial truncado. El SDKs uso de un retardo exponencial binario truncado con fluctuación de fase. El siguiente algoritmo muestra cómo se define la cantidad de tiempo de reposo, en segundos, para una respuesta a una solicitud i:

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

En el algoritmo anterior, se aplican los siguientes valores:

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

r = 2

MAX_BACKOFF = 20 secondsSDKspara la mayoría. Consulta tu SDK guía específica o tu código fuente para confirmarlo.

Compatibilidad con AWS SDKs

Las siguientes opciones SDKs son compatibles con las funciones y configuraciones descritas en este tema. Se anotan todas las excepciones parciales. Cualquier configuración de propiedades del JVM sistema es compatible con la AWS SDK for Java y el AWS SDK para Kotlin únicamente.