Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Nesta página, descrevemos as práticas recomendadas para repetir solicitações com falha para a
API Identity and Access Management (IAM).
Para solicitações que podem ser repetidas, use a espera exponencial truncada com instabilidade introduzida.
Visão geral da espera exponencial truncada
Cada solicitação para a API IAM pode ser bem-sucedida ou não. Se o aplicativo repetir
solicitações com falha sem esperar, ele poderá enviar um grande número de tentativas para o IAM
em um curto período. Como resultado, pode haver exceção de cotas e limites que se aplicam a todos
os recursos do IAM no projeto Google Cloud .
Para evitar o acionamento desse problema, recomendamos o uso da
espera exponencial truncada com
instabilidade introduzida, que é uma estratégia
padrão de tratamento de erros para aplicativos de rede. Nessa abordagem, um cliente repete de maneira periódica
uma solicitação com falha, com atrasos exponencialmente crescentes entre as novas tentativas. Um pequeno atraso aleatório,
conhecido como instabilidade, também é adicionado entre as novas tentativas. Esse atraso aleatório ajuda a evitar uma onda
sincronizada de novas tentativas de vários clientes, também conhecida como
problema de excesso de acionamentos.
Algoritmo de espera exponencial
O algoritmo a seguir implementa a espera exponencial truncada com instabilidade:
Envie uma solicitação para o IAM.
Se a solicitação falhar, aguarde 1 + random-fraction segundos e repita a solicitação.
Se a solicitação falhar, aguarde 2 + random-fraction segundos e repita a solicitação.
Se a solicitação falhar, aguarde 4 + random-fraction segundos e repita a solicitação.
Continue esse padrão, aguardando 2n + random-fraction segundos após cada
nova tentativa, até o máximo de maximum-backoff.
Depois de deadline segundos, pare de repetir a solicitação.
Use os seguintes valores ao implementar o algoritmo:
Antes de cada nova tentativa, o tempo de espera é de
min((2n + random-fraction), maximum-backoff), com n
a partir de 0 e incrementado em 1 para cada nova tentativa.
Substitua random-fraction por um valor fracionário aleatório menor ou igual a 1. Use
um valor diferente para cada nova tentativa. Adicionar esse valor aleatório evita que os clientes sejam
sincronizados e enviem um grande número de novas tentativas ao mesmo tempo.
Substitua maximum-backoff pelo tempo máximo, em segundos, para aguardar
entre as novas tentativas. Os valores típicos são 32 ou 64 (25 ou 26) segundos. Escolha
o valor ideal para seu caso de uso.
Substitua deadline pelo número máximo de segundos para continuar enviando novas tentativas. Escolha
um valor que reflita seu caso de uso. Por exemplo, em um pipeline de integração/implantação
contínuas (CI/CD) que não seja altamente urgente, defina
deadline como 300 segundos (5 minutos).
Tipos de erros para tentar novamente
Use essa estratégia de repetição para todas as solicitações à API IAM que
retornam os códigos de erro 500, 502, 503 ou 504.
Como opção, é possível usar essa estratégia de nova tentativa para solicitações à
API IAM que retornam o código de erro 404.
As leituras do IAM têm consistência eventual. Como
resultado, os recursos podem não estar visíveis imediatamente após a criação, o que
pode gerar erros 404.
Além disso, use uma versão modificada dessa estratégia de repetição para todas as solicitações
à API IAM que retornam o código de erro 409 e o status
ABORTED. Esse tipo de erro indica um problema de simultaneidade. Por exemplo, talvez
você esteja tentando atualizar uma política de permissão que outro
cliente já substituiu. Para esse tipo de erro, você deve sempre repetir
toda a série de solicitações read-modify-write, usando
a espera exponencial truncada com instabilidade introduzida. Se você repetir somente a operação de gravação, a solicitação
continuará com erros.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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."]]