Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
La retirada exponencial es una estrategia estándar de manejo de errores para aplicaciones de red en la que el cliente vuelve a intentar una solicitud con errores de forma periódica, cada vez con menos frecuencia entre las solicitudes. Los clientes deben usar la retirada exponencial en todas las solicitudes a Memorystore para Redis que muestren errores de código de respuesta HTTP 5xx y 429.
Comprender el funcionamiento de la retirada exponencial es importante si deseas realizar las siguientes acciones:
Compilar aplicaciones cliente que usen directamente la API de REST de Memorystore para Redis.
Si usas la consola deGoogle Cloud , la consola envía solicitudes a Memorystore para Redis en tu nombre y se encarga de cualquier retirada necesaria.
Algoritmo de ejemplo
Un algoritmo de retirada exponencial vuelve a intentar las solicitudes de forma exponencial, lo que aumenta el tiempo de espera entre los reintentos hasta un tiempo de retirada máximo. A continuación, se presenta un ejemplo:
Realiza una solicitud a Memorystore para Redis.
Si la solicitud falla, espera 1 + random_number_milliseconds segundos y vuelve a intentar la solicitud.
Si la solicitud falla, espera 2 + random_number_milliseconds segundos y vuelve a intentar la solicitud.
Si la solicitud falla, espera 4 + random_number_milliseconds segundos y vuelve a intentar la solicitud.
Y así sucesivamente, hasta un tiempo de maximum_backoff.
Continúa con la espera y los reintentos hasta un número máximo de reintentos, pero no aumentes el período de espera entre los reintentos.
Donde:
El tiempo de espera es min(((2^n) + random_number_milliseconds), maximum_backoff), con n incrementado en 1 para cada iteración (solicitud).
random_number_milliseconds es un número al azar de milisegundos menor o igual que 1,000. Esto ayuda a evitar los casos en que muchos clientes se sincronizan por alguna situación y todos vuelven a intentarlo a la vez, lo que hace que se envíen solicitudes sincronizadas en cantidad. El valor de random_number_milliseconds se debe volver a calcular después de cada solicitud de reintento.
maximum_backoff suele ser de 32 o 64 segundos. El valor apropiado depende del caso práctico.
Puedes continuar con los reintentos una vez que alcances el tiempo maximum_backoff.
Después de este punto, los reintentos no necesitan continuar con el aumento del tiempo de retirada. Por ejemplo, si un cliente usa un tiempo maximum_backoff de 64 segundos, luego de alcanzar este valor, el cliente puede volver a intentarlo cada 64 segundos. En algún momento, se debe evitar que los clientes vuelvan a intentarlo de forma ilimitada.
La cantidad máxima de retiradas y la cantidad máxima de reintentos que usa un cliente dependen del caso práctico y de las condiciones de la red. Por ejemplo, es posible que los clientes móviles de una aplicación deban intentar más veces y por intervalos más largos, en comparación con los clientes de escritorio de la misma aplicación.
Si las solicitudes de reintento fallan después de exceder la cantidad máxima de reintentos, informa o registra un error mediante uno de los métodos que se indican en Obtén asistencia.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-05 (UTC)"],[],[],null,["# Exponential backoff\n\n[Exponential backoff](https://en.wikipedia.org/wiki/Exponential_backoff) is a standard error handling\nstrategy for network applications in which a client periodically retries a\nfailed request with increasing delays between requests. Clients should use\nexponential backoff for all requests to Memorystore for Redis that return\nHTTP `5xx` and `429` response code errors.\n\nUnderstanding how exponential backoff works is important if you are:\n\n- Building client applications that use the Memorystore for Redis [REST API](/memorystore/docs/redis/reference/rest)\n directly.\n\n- Accessing Memorystore for Redis through a [client library](/memorystore/docs/redis/libraries).\n Note that some client libraries, such as the [Memorystore for Redis Client Library for Node.js](https://googleapis.dev/nodejs/redis/latest/index.html),\n have built-in exponential backoff.\n\nIf you are using the [Google Cloud console](https://console.cloud.google.com/), the console sends\nrequests to Memorystore for Redis on your behalf and handles any necessary\nbackoff.\n\nExample algorithm\n-----------------\n\nAn exponential backoff algorithm retries requests exponentially,\nincreasing the waiting time between retries up to a maximum backoff time. An\nexample is:\n\n1. Make a request to Memorystore for Redis.\n\n2. If the request fails, wait 1 + `random_number_milliseconds` seconds and retry\n the request.\n\n3. If the request fails, wait 2 + `random_number_milliseconds` seconds and retry\n the request.\n\n4. If the request fails, wait 4 + `random_number_milliseconds` seconds and retry\n the request.\n\n5. And so on, up to a `maximum_backoff` time.\n\n6. Continue waiting and retrying up to some maximum number of retries, but\n do not increase the wait period between retries.\n\nwhere:\n\n- The wait time is min(((2\\^`n`)+`random_number_milliseconds`), `maximum_backoff`),\n with `n` incremented by 1 for each iteration (request).\n\n- `random_number_milliseconds` is a random number of milliseconds less than or\n equal to 1000. This helps to avoid cases where many clients get synchronized by\n some situation and all retry at once, sending requests in synchronized\n waves. The value of `random_number_milliseconds` should be recalculated after\n each retry request.\n\n- `maximum_backoff` is typically 32 or 64 seconds. The appropriate value\n depends on the use case.\n\nIt's okay to continue retrying once you reach the `maximum_backoff` time.\nRetries after this point do not need to continue increasing backoff time. For\nexample, if a client uses an `maximum_backoff` time of 64 seconds, then after\nreaching this value, the client can retry every 64 seconds. At some point,\nclients should be prevented from retrying infinitely.\n\nThe maximum backoff and maximum number of retries that a client uses\ndepends on the use case and network conditions. For example, mobile\nclients of an application may need to retry more times and for longer intervals\nwhen compared to desktop clients of the same application.\n\nIf the retry requests fail after exceeding the maximum number of retries, report\nor log an error using one of the methods listed under [Getting support](/memorystore/docs/redis/getting-support)."]]
