Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Ein exponentieller Backoff ist eine Standardstrategie zur Fehlerbehebung für Netzwerkanwendungen, bei der ein Client eine fehlgeschlagene Anfrage regelmäßig noch einmal sendet, wobei die Abstände zwischen den Anfragen immer länger werden. Clients sollten für alle Anfragen an Memorystore for Redis, die HTTP-5xx- und 429-Antwortcodefehler zurückgeben, einen exponentiellen Backoff verwenden.
Für die folgenden Vorgänge ist es wichtig, die Funktionsweise des exponentiellen Backoffs zu verstehen:
Beim Erstellen von Clientanwendungen, die die Memorystore for Redis REST API direkt verwenden.
Wenn Sie die Google Cloud -Console verwenden, sendet diese in Ihrem Namen Anfragen an Memorystore for Redis und verarbeitet erforderliche Backoffs.
Beispielalgorithmus
Ein exponentieller Backoff-Algorithmus wiederholt Anfragen exponentiell und verlängert dabei die Wartezeit zwischen zwei Wiederholungen bis zur maximalen Backoff-Zeit. Ein Beispiel:
Senden Sie eine Anfrage an Memorystore for Redis.
Wenn die Anfrage fehlschlägt, wartet das System 1 + random_number_milliseconds Sekunden und wiederholt dann die Anfrage.
Wenn die Anfrage fehlschlägt, wartet das System 2 + random_number_milliseconds Sekunden und wiederholt dann die Anfrage.
Wenn die Anfrage fehlschlägt, wartet das System 4 + random_number_milliseconds Sekunden und wiederholt dann die Anfrage.
Und so weiter bis zur maximum_backoff-Zeit.
Das System wartet weiter und führt erneute Versuche bis zu einer maximalen Anzahl an Wiederholungsversuchen aus, jedoch ohne den zeitlichen Abstand zwischen zwei Versuchen zu erhöhen.
wobei
Die Wartezeit beträgt min(((2^n)+random_number_milliseconds), maximum_backoff), wobei n bei jeder Ausführung (Anfrage) um 1 erhöht wird.
random_number_milliseconds steht für eine zufällige Anzahl von Millisekunden, deren Wert größer oder gleich 1.000 ist. So lassen sich Situationen vermeiden, in denen viele Clients synchronisiert werden und alle gleichzeitig Anfragen wiederholen und diese in synchronisierten Wellen senden. Der Wert von random_number_milliseconds sollte nach jeder Anfragewiederholung neu berechnet werden.
maximum_backoff ist normalerweise 32 oder 64 Sekunden lang. Der geeignete Wert hängt vom jeweiligen Anwendungsfall ab.
Sie können das System weitere Wiederholungen ausführen lassen, nachdem die maximum_backoff-Zeit abgelaufen ist.
Die Backoff-Zeit muss dabei nicht mehr verlängert werden. Wenn ein Client beispielsweise eine maximum_backoff-Zeit von 64 Sekunden verwendet, kann er nach Erreichen dieses Werts die Anfrage alle 64 Sekunden noch einmal senden. Sie sollten jedoch dafür sorgen, dass er dies nicht unbegrenzt tut.
Der maximale Backoff und die maximale Anzahl von Wiederholungsversuchen, die ein Client verwendet, hängen vom Anwendungsfall und den Netzwerkbedingungen ab. Mobile Clients einer Anwendung müssen unter Umständen mehr Wiederholungen mit längeren Intervallen ausführen als Desktopclients derselben Anwendung.
Wenn die Wiederholungsanfragen nach Überschreiten der maximalen Anzahl von Wiederholungsversuchen fehlschlagen, melden oder loggen Sie einen Fehler mithilfe einer der Methoden, die unter Support erhalten aufgeführt sind.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-04 (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)."]]
