지수 백오프는 요청 간 지연 증가와 함께 클라이언트가 주기적으로 실패한 요청을 재시도하는 네트워크 애플리케이션의 표준 오류 처리 전략입니다. 클라이언트는 HTTP 5xx 및 429 응답 코드 오류를 반환하는 Memorystore for Redis로의 모든 요청에 지수 백오프를 사용해야 합니다.
다음과 같은 경우 지수 백오프 작동 방식을 이해하는 것이 중요합니다.
Memorystore for Redis REST API를 직접 사용하는 클라이언트 애플리케이션을 빌드하는 경우.
Google Cloud 콘솔을 사용하는 경우 콘솔은 사용자 대신 Memorystore for Redis에 요청을 보내고 필요한 백오프를 처리합니다.
예시 알고리즘
지수 백오프 알고리즘이 재시도 간 대기 시간을 최대 백오프 시간까지 늘려서 기하급수적으로 요청을 재시도합니다. 예를 들면 다음과 같습니다.
Memorystore for Redis에 요청합니다.
요청이 실패하면 1초 + random_number_milliseconds를 대기한 후 요청을 재시도합니다.
요청이 실패하면 2초 + random_number_milliseconds를 대기한 후 요청을 재시도합니다.
요청이 실패하면 4초 + random_number_milliseconds를 대기한 후 요청을 재시도합니다.
maximum_backoff 시간까지 이를 반복합니다.
최대 재시도 횟수까지 계속 대기하고 재시도합니다. 그러나 재시도 간 대기 시간을 늘리지 않습니다.
각 항목의 의미는 다음과 같습니다.
대기 시간은 min(((2^n)+random_number_milliseconds), maximum_backoff)입니다. 여기에서 n은 반복(요청)마다 1씩 증가합니다.
random_number_milliseconds는 1,000밀리초 이하의 임의 숫자입니다. 이는 많은 클라이언트가 어떤 상황에 의해 동기화되고 모든 요청이 한 번에 재시도되어 동기화된 웨이브로 요청을 보내는 경우를 피하는 데 도움이 됩니다. random_number_milliseconds 값은 재시도 요청을 할 때마다 다시 계산되어야 합니다.
maximum_backoff는 일반적으로 32 또는 64초입니다. 적절한 값은 사용 사례에 따라 다릅니다.
maximum_backoff 시간에 도달한 후에는 계속 재시도해도 좋습니다.
이후 재시도는 백오프 시간을 계속 늘릴 필요가 없습니다. 예를 들어 클라이언트가 maximum_backoff 시간으로 64초를 사용하는 경우 이 값에 도달한 후 클라이언트는 64초마다 재시도할 수 있습니다. 특정 시점에서 클라이언트가 무한정 재시도하지 못하게 해야 합니다.
클라이언트가 사용하는 최대 백오프 및 최대 재시도 횟수는 사용 사례 및 네트워크 조건에 따라 다릅니다 예를 들어 애플리케이션의 모바일 클라이언트는 동일한 애플리케이션의 데스크톱 클라이언트보다 더 자주, 더 긴 간격으로 재시도해야 할 수 있습니다.
최대 재시도 횟수를 초과한 후 재시도 요청이 실패하면 지원 및 도움말에 나열된 방법 중 하나로 오류를 신고하거나 로깅합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 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)."]]
