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.

Configure esta funcionalidad mediante lo siguiente:

retry_mode- configuración de AWS config archivos compartidos

AWS_RETRY_MODE: variable de entorno

aws.retryMode- propiedad JVM del sistema: solo en Java/Kotlin

Especifica cómo intenta la herramienta de desarrollador SDK volver a intentarlo.

Valor predeterminado: este valor es específico de su. SDK Consulta tu SDK guía específica o tu base SDK de código para ver si está predeterminadaretry_mode.

Valores válidos:

• standard— (Recomendado) El conjunto recomendado de reglas de reintento para todos AWS SDKs. Este modo incluye un conjunto estándar de errores que se repiten y ajusta automáticamente el número de reintentos para maximizar la disponibilidad y la estabilidad. Este modo es seguro para su uso en aplicaciones multiusuario. El número máximo predeterminado de intentos con este modo es tres, a menos que los max_attempts se configuren de forma explícita.

• adaptive— Un modo de reintento, adecuado solo para casos de uso especializados, que incluye la funcionalidad del modo estándar, así como una limitación automática de la velocidad por parte del cliente. Este modo de reintento no se recomienda para aplicaciones con varios usuarios, a menos que se procure aislar a los inquilinos de las aplicaciones. Para obtener más información, consulte Elegir entre los modos standard y adaptive volver a intentarlo. Este modo es experimental y podría cambiar su comportamiento en el futuro.

• legacy— (No recomendado) Específico para SDK ti (consulta tu SDK guía específica o tu SDK código base).

max_attempts- configuración de AWS config archivos compartidos

AWS_MAX_ATTEMPTS: variable de entorno

aws.maxAttempts- propiedad JVM del sistema: solo en Java/Kotlin

Especifica el número máximo de intentos que se pueden realizar en una solicitud.

Valor predeterminado: si no se especifica este valor, su valor predeterminado depende del valor de la configuración retry_mode:

• Si retry_mode lo estálegacy: usa un valor predeterminado específico para usted SDK (consulte su SDK guía específica o su base SDK de código para max_attempts ver el valor predeterminado).

• Si el retry_mode es standard: realiza tres intentos.

• Si el retry_mode es adaptive: realiza tres intentos.

Valores válidos: un número mayor que 0.

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

nota

El adaptive modo presupone que se agrupan los clientes en función del ámbito en el que el servicio de backend puede limitar las solicitudes. Si no lo haces, la limitación de un recurso podría retrasar las solicitudes de un recurso no relacionado si utilizas el mismo cliente para ambos recursos.

Estándar	Adaptativo
Casos de uso de aplicaciones: todos.	Casos de uso de aplicaciones: No es sensible a la latencia. El cliente solo accede a un único recurso, o bien, usted proporciona una lógica para agrupar a sus clientes por separado según el recurso de servicio al que se accede.
Admite la interrupción de circuitos para evitar que se vuelvan a intentar durante SDK las interrupciones.	Admite la interrupción del circuito para evitar que se vuelva a intentar durante las interrupciones. SDK
Utiliza un retroceso exponencial fluctuante en caso de averías.	Utiliza tiempos de espera dinámicos para intentar minimizar el número de solicitudes fallidas, a cambio de la posibilidad de aumentar la latencia.
Nunca retrasa el primer intento de solicitud, solo los reintentos.	Puede acelerar o retrasar el intento de solicitud inicial.

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, es más preciso que pensar en cada uno de ellos. Servicio de AWS Servicios de AWS pueden tener dimensiones adicionales que utilizan para limitar las solicitudes. Usemos el servicio Amazon DynamoDB como ejemplo. DynamoDB Región de AWS usa plus la tabla a la que se accede para acelerar las solicitudes. Esto significa que una tabla a la que accede el 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 experimenta una latencia inesperada al usar el adaptive modo, consulte la guía de AWS documentación específica del servicio que esté utilizando.

Detalles de implementación del modo de reintento

Se utilizan 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. AWS SDKs El grupo utiliza dos grupos de fichasSDK: un grupo de fichas de reintentos y un grupo de fichas de tasa de solicitudes.

• El depósito de reintentos se utiliza para determinar si se SDK deben deshabilitar temporalmente los reintentos a fin de proteger los servicios ascendentes y descendentes durante las interrupciones. Los tokens se obtienen del depósito antes de que se intenten reintentarlo y, cuando las solicitudes se realizan correctamente, se devuelven al depósito. Si el depósito está vacío cuando se intenta reintentar, no SDK volverá a intentar la solicitud.

• El depósito de fichas de tasa de solicitudes solo se usa en el modo de adaptive reintento para determinar la velocidad a la que se envían las solicitudes. Los tokens se adquieren del depósito antes de que se envíe la solicitud y se devuelven al depósito a un ritmo determinado dinámicamente en función de la limitación de las respuestas devueltas por el servicio.

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:

Este paso envía la solicitud a. AWS La mayoría AWS SDKs usa una HTTP biblioteca que usa 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:

• El código HTTP de estado.

• El código de error devuelto por el servicio.

• Los errores de conexión, definidos como cualquier error recibido por SDK el que no se recibe una HTTP respuesta del servicio.

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 AWS SDK for Java y AWS SDK para Kotlin únicamente.

SDK	Compatible	Notas o más información
AWS CLI  v2	Sí
SDKpara C++	Sí
SDKpara Go V2 (1.x)	Sí
SDKpara Go 1.x (V1)	No
SDKpara Java 2.x	Sí
SDKpara Java 1.x	Sí	JVMpropiedades del sistema: usar com.amazonaws.sdk.maxAttempts en lugar deaws.maxAttempts; usar com.amazonaws.sdk.retryMode en lugar deaws.retryMode.
SDKpara JavaScript 3.x	Sí
SDKpara JavaScript 2.x	No	Admite un número máximo de reintentos, el retroceso exponencial con fluctuación de fase y la opción de un método personalizado para el retraso de los reintentos.
SDKpara Kotlin	Sí
SDKpara. NET3.x	Sí
SDKpara PHP 3.x	Sí
SDKpara Python (Boto3)	Sí
SDKpara Ruby 3.x	Sí
SDKpara Rust	Sí
Herramientas para PowerShell	Sí