Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Auf dieser Seite werden Best Practices für die Wiederholung fehlgeschlagener Anfragen an die Identity and Access Management (IAM) API beschrieben.
Bei Anfragen, die sicher wiederholt werden können, empfehlen wir die Verwendung des abgeschnittenen exponentiellen Backoffs mit eingeführtem Jitter.
Abgeschnittener exponentieller Backoff
Jede Anfrage an die IAM API kann erfolgreich sein oder fehlschlagen. Wenn Ihre Anwendung fehlgeschlagene Anfragen ohne Wartezeit wiederholt, kann sie innerhalb kurzer Zeit eine große Anzahl von Wiederholungsversuchen an IAM senden. Infolgedessen können Sie Kontingente und Limits überschreiten, die für jede IAM-Ressource in Ihrem Google Cloud-Projekt gelten.
Zur Vermeidung dieses Problems empfehlen wir dringend, den abgeschnittenen exponentiellen Backoff mit dem eingeführten Jitter zu verwenden. Dies ist eine Standardstrategie zur Fehlerbehandlung für Netzwerkanwendungen. Bei diesem Ansatz wiederholt ein Client regelmäßig eine fehlgeschlagene Anfrage mit exponentiell zunehmenden Verzögerungen zwischen den Wiederholungen. Zwischen den Wiederholungen wird auch eine kleine, zufällige Verzögerung, die als Jitter bezeichnet wird, hinzugefügt. Diese zufällige Verzögerung verhindert, dass eine synchronisierte Welle von Wiederholungsversuchen von mehreren Clients entsteht, auch als Thundering-Herd-Problem bezeichnet wird.
Exponentieller Backoff-Algorithmus
Der folgende Algorithmus implementiert einen abgeschnittenen exponentiellen Backoff mit Jitter:
Senden Sie eine Anfrage an IAM.
Wenn die Anfrage fehlschlägt, wartet das System 1 + random-fraction Sekunden und wiederholt dann die Anfrage.
Wenn die Anfrage fehlschlägt, wartet das System 2 + random-fraction Sekunden und wiederholt dann die Anfrage.
Wenn die Anfrage fehlschlägt, wartet das System 4 + random-fraction Sekunden und wiederholt dann die Anfrage.
Setzen Sie dieses Muster fort und warten Sie nach jedem Versuch 2n + random-fraction Sekunden bis zu einer Zeit von maximum-backoff.
Beenden Sie das Wiederholen der Anfrage nach deadline Sekunden.
Verwenden Sie beim Implementieren des Algorithmus die folgenden Werte:
Vor jeder Wiederholung ist die Wartezeit min((2n + random-fraction), maximum-backoff), wobei n bei 0 beginnt und bei jeder Wiederholung um 1 erhöht wird.
Ersetzen Sie random-fraction durch einen zufälligen Bruchwert, der kleiner oder gleich 1 ist. Verwenden Sie für jede Wiederholung einen anderen Wert. Durch das Hinzufügen dieses zufälligen Werts wird verhindert, dass Clients synchronisiert werden und eine große Anzahl von Wiederholungsversuchen gleichzeitig gesendet werden.
Ersetzen Sie maximum-backoff durch die maximale Zeit in Sekunden, die zwischen Wiederholungen gewartet werden soll. Übliche Werte sind 32 oder 64 Sekunden (25 oder 26 Sekunden). Wählen Sie den Wert aus, der sich für Ihren Anwendungsfall am besten eignet.
Ersetzen Sie deadline durch die maximale Anzahl von Sekunden, die Wiederholungsversuche gesendet werden sollen. Wählen Sie einen Wert, der Ihren Anwendungsfall widerspiegelt. Beispiel: In einer CI/CD-Pipeline (Continuous Integration/Continuous Deployment), die nicht besonders zeitkritisch ist, können Sie deadline auf 300 Sekunden (5 Minuten) festlegen.
Arten von Fehlern, die wiederholt werden sollen
Verwenden Sie diese Wiederholungsstrategie für alle Anfragen an die IAM API, die die Fehlercodes 500, 502, 503 oder 504 zurückgeben.
Optional können Sie diese Wiederholungsstrategie für Anfragen an die IAM API verwenden, die den Fehlercode 404 zurückgeben.
IAM-Lesevorgänge weisen Eventual Consistency auf; Ressourcen sind daher nach der Erstellung möglicherweise nicht sichtbar, was zu 404-Fehlern führen kann.
Verwenden Sie außerdem eine modifizierte Version dieser Wiederholungsstrategie für alle Anfragen an die IAM API, die den Fehlercode 409 und den Status ABORTED zurückgeben. Diese Art von Fehler weist auf ein Problem mit der Gleichzeitigkeit hin. Beispiel: Sie versuchen, eine Zulassungsrichtlinie zu aktualisieren, die ein anderer Client bereits überschrieben hat. Für diesen Fehler sollten Sie immer die gesamte Read-Modify-Write-Reihe (Lesen-Ändern-Schreiben) der Anfragen wiederholen und dafür einen abgeschnittenen exponentiellen Backoff mit einem eingeführten Jitter verwenden. Wenn Sie nur den Schreibvorgang wiederholen, schlägt die Anfrage weiterhin fehl.
[[["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-08-28 (UTC)."],[[["\u003cp\u003eThis document outlines best practices for retrying failed requests to the Identity and Access Management (IAM) API, recommending the use of truncated exponential backoff with jitter for safe-to-retry requests.\u003c/p\u003e\n"],["\u003cp\u003eUsing truncated exponential backoff with jitter helps prevent overwhelming the IAM API with a large number of retries, which can lead to exceeding project quotas and limits.\u003c/p\u003e\n"],["\u003cp\u003eThe retry algorithm involves exponentially increasing wait times between retries, with the addition of a random delay (jitter) to avoid synchronized retries from multiple clients, and a cap on the wait time, followed by a final deadline.\u003c/p\u003e\n"],["\u003cp\u003eThe recommended retry strategy should be used for IAM API requests that return \u003ccode\u003e500\u003c/code\u003e, \u003ccode\u003e502\u003c/code\u003e, \u003ccode\u003e503\u003c/code\u003e, or \u003ccode\u003e504\u003c/code\u003e error codes, and optionally \u003ccode\u003e404\u003c/code\u003e errors due to eventual consistency, and a modified version should be used for \u003ccode\u003e409\u003c/code\u003e \u003ccode\u003eABORTED\u003c/code\u003e errors.\u003c/p\u003e\n"],["\u003cp\u003eFor \u003ccode\u003e409\u003c/code\u003e errors, which typically signify concurrency issues, you should retry the entire read-modify-write series of requests, as retrying only the write operation will not resolve the issue.\u003c/p\u003e\n"]]],[],null,["# Retry failed requests\n\nThis page describes best practices for retrying failed requests to the\nIdentity and Access Management (IAM) API.\n\nFor requests that are safe to retry, we recommend using truncated exponential backoff with introduced jitter.\n\nOverview of truncated exponential backoff\n-----------------------------------------\n\n\nEach request to the IAM API can succeed or fail. If your application retries\nfailed requests without waiting, it might send a large number of retries to IAM\nin a short period of time. As a result, you might exceed [quotas and limits](/iam/quotas) that apply to every\nIAM resource in your Google Cloud project.\n\n\nTo avoid triggering this issue, we strongly recommend that you use\n[truncated exponential backoff](https://en.wikipedia.org/wiki/Exponential_backoff) with\nintroduced [jitter](https://en.wikipedia.org/wiki/Jitter), which is a standard\nerror-handling strategy for network applications. In this approach, a client periodically retries\na failed request with exponentially increasing delays between retries. A small, random delay,\nknown as jitter, is also added between retries. This random delay helps prevent a synchronized\nwave of retries from multiple clients, also known as the\n[thundering herd problem](https://en.wikipedia.org/wiki/Thundering_herd_problem).\n\nExponential backoff algorithm\n-----------------------------\n\n\nThe following algorithm implements truncated exponential backoff with jitter:\n\n1. Send a request to IAM.\n2. If the request fails, wait 1 + `random-fraction` seconds, then retry the request.\n3. If the request fails, wait 2 + `random-fraction` seconds, then retry the request.\n4. If the request fails, wait 4 + `random-fraction` seconds, then retry the request.\n5. Continue this pattern, waiting 2^n^ + `random-fraction` seconds after each retry, up to a `maximum-backoff` time.\n6. After `deadline` seconds, stop retrying the request.\n\n\nUse the following values as you implement the algorithm:\n\n- Before each retry, the wait time is `min((2`^n^` + random-fraction), maximum-backoff)`, with `n` starting at 0 and incremented by 1 for each retry.\n- Replace `random-fraction` with a random fractional value less than or equal to 1. Use a different value for each retry. Adding this random value prevents clients from becoming synchronized and sending large numbers of retries at the same time.\n- Replace `maximum-backoff` with the maximum amount of time, in seconds, to wait between retries. Typical values are 32 or 64 (2^5^ or 2^6^) seconds. Choose the value that works best for your use case.\n- Replace `deadline` with the maximum number of seconds to keep sending retries. Choose a value that reflects your use case. For example, in a continuous integration/continuous deployment (CI/CD) pipeline that is not highly time-sensitive, you might set `deadline` to 300 seconds (5 minutes).\n\nTypes of errors to retry\n------------------------\n\nUse this retry strategy for all requests to the IAM API that\nreturn the error codes `500`, `502`, `503`, or `504`.\n\nOptionally, you can use this retry strategy for requests to the\nIAM API that return the error code `404`.\n[IAM reads are eventually consistent](/iam/docs/overview#consistency); as a\nresult, resources might not be visible immediately after you create them, which\ncan lead to `404` errors.\n\nIn addition, use a modified version of this retry strategy for all requests to\nthe IAM API that return the error code `409` and the status\n`ABORTED`. This type of error indicates a concurrency issue; for example, you\nmight be trying to update an [allow policy](/iam/docs/allow-policies) that another client has\nalready overwritten. For this type of error, you should always retry the entire\n[read-modify-write](/iam/docs/allow-policies#etag) series of requests, using\ntruncated exponential backoff with introduced jitter. If you retry only the write operation, the request will\ncontinue to fail.\n\nWhat's next\n-----------\n\n- Learn [how concurrency issues are managed](/iam/docs/allow-policies#etag) in allow policies.\n- Understand how to [implement the read-modify-write pattern](/iam/docs/granting-changing-revoking-access#programmatic) for updating allow policies."]]
