Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Halaman ini menjelaskan praktik terbaik untuk mencoba kembali permintaan yang gagal ke
Identity and Access Management (IAM) API.
Untuk permintaan yang aman untuk dicoba lagi, sebaiknya gunakan backoff eksponensial terpotong dengan jitter yang disisipkan.
Ringkasan backoff eksponensial terpotong
Setiap permintaan ke IAM API dapat berhasil atau juga gagal. Jika aplikasi Anda mencoba ulang
permintaan yang gagal tanpa menunggu, aplikasi tersebut mungkin akan mengirimkan sejumlah besar percobaan ulang ke IAM
dalam waktu singkat. Akibatnya, Anda mungkin melebihi kuota dan batas yang berlaku untuk setiap
resource IAM dalam project Google Cloud Anda.
Untuk menghindari pemicuan masalah ini, sebaiknya gunakan
backoff eksponensial terpotong dengan
jitter yang disisipkan, yang merupakan strategi
penanganan error standar untuk aplikasi jaringan. Dalam pendekatan ini, klien secara berkala mencoba kembali
permintaan yang gagal dengan penundaan yang meningkat secara eksponensial di antara percobaan ulang. Penundaan acak kecil,
yang dikenal sebagai jitter, juga disisipkan di antara percobaan ulang. Penundaan acak ini membantu mencegah terjadinya rentetan
percobaan ulang yang tersinkronisasi dari beberapa klien yang juga dikenal sebagai
masalah kawanan guntur.
Algotitma backoff eksponensial
Algoritme berikut menerapkan backoff eksponensial terpotong dengan jitter:
Kirim permintaan ke IAM.
Jika permintaan gagal, tunggu 1 + random-fraction detik, lalu coba lagi permintaan tersebut.
Jika permintaan gagal, tunggu 2 + random-fraction detik, lalu coba lagi permintaan tersebut.
Jika permintaan gagal, tunggu 4 + random-fraction detik, lalu coba lagi permintaan tersebut.
Lanjutkan pola ini, menunggu 2n + random-fraction detik setelah setiap
percobaan ulang, hingga maximum-backoff kali.
Setelah deadline detik, berhenti mencoba lagi permintaan tersebut.
Gunakan nilai berikut saat Anda mengimplementasikan algoritme:
Sebelum setiap percobaan ulang, waktu tunggu adalah
min((2n + random-fraction), maximum-backoff), dengan n
dimulai dari 0 dan bertambah 1 untuk setiap percobaan ulang.
Ganti random-fraction dengan nilai pecahan acak yang kurang dari atau sama dengan 1. Gunakan
nilai yang berbeda untuk setiap percobaan ulang. Menambahkan nilai acak ini mencegah klien menjadi
tersinkronisasi dan mengirim percobaan ulang dalam jumlah besar secara bersamaan.
Ganti maximum-backoff dengan jumlah waktu maksimum, dalam detik, untuk menunggu
di antara percobaan ulang. Nilai yang umum adalah 32 atau 64 (25 atau 26) detik. Pilih
nilai yang paling sesuai untuk kasus penggunaan Anda.
Ganti deadline dengan jumlah detik maksimum untuk terus mengirim percobaan ulang. Pilih
nilai yang mencerminkan kasus penggunaan Anda. Misalnya, dalam pipeline continuous integration/deployment
berkelanjutan (CI/CD) yang tidak terlalu sensitif terhadap waktu, Anda dapat menetapkan
deadline ke 300 detik (5 menit).
Jenis error yang dapat dicoba ulang
Gunakan strategi percobaan ulang ini untuk semua permintaan ke IAM API yang
menampilkan kode error 500, 502, 503, atau 504.
Secara opsional, Anda dapat menggunakan strategi percobaan ulang ini untuk permintaan ke
IAM API yang menampilkan kode error 404.
Pembacaan IAM adalah pembacaan dengan konsistensi tertunda; Akibatnya,
resource mungkin tidak langsung terlihat setelah Anda membuatnya, yang
dapat menyebabkan error 404.
Selain itu, gunakan versi modifikasi dari strategi percobaan ulang ini untuk
semua permintaan ke IAM API yang menampilkan kode error 409 dan status
ABORTED. Jenis error ini menunjukkan masalah konkurensi; misalnya, Anda
mungkin mencoba mengupdate kebijakan perizinan yang telah
ditimpa oleh klien lain. Untuk jenis error ini, Anda harus selalu mencoba ulang seluruh
rangkaian permintaan baca-ubah-tulis., menggunakan
backoff eksponensial terpotong dengan jitter yang disisipkanj. Jika Anda hanya mencoba ulang operasi tulis, permintaan tersebut akan
terus gagal.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-08-21 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."]]
