重试失败的请求

使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

本页面介绍重试对 Identity and Access Management (IAM) API 的失败请求的最佳做法。

对于可安全重试的请求，我们建议使用截断指数退避算法并引入抖动。

截断指数退避算法概览

对 IAM API 的每个请求可能会成功，也可能会失败。如果您的应用未等待就重试失败的请求，则可能会在短时间内向 IAM 发送大量重试。因此，您可能会超出 Google Cloud 项目中每个 IAM 资源的配额和限制。

为避免触发此问题，我们强烈建议您使用截断指数退避算法并引入抖动，这是一个针对网络应用的标准错误处理策略。在此方法中，客户端会定期重试失败的请求，并以指数级增加各次重试之间的延迟时间。在两次重试之间，还会增加一个随机的小延迟，称为抖动。这种随机延迟有助于防止多个客户端同步重试（也称为惊群问题）。

指数退避算法

以下算法使用抖动实现截断的指数退避算法：

1. 向 IAM 发送请求。
2. 如果请求失败，请等待 1 + random-fraction 秒后再重试请求。
3. 如果请求失败，请等待 2 + random-fraction 秒后再重试请求。
4. 如果请求失败，请等待 4 + random-fraction 秒后再重试请求。
5. 继续此模式，每次重试后等待 2ⁿ + random-fraction 秒，最多 maximum-backoff 次。
6. deadline 秒后，停止重试请求。

在实现算法时，请使用以下值：

• 每次重试之前，等待时间为 min((2n + random-fraction), maximum-backoff)，其中 n 从 0 开始，并在每次重试时递增 1。
• 将 random-fraction 替换为小于或等于 1 的随机小数值。每次重试使用不同的值。添加此随机值可防止客户端同步和同时发送大量重试。
• 将 maximum-backoff 替换为重试之间等待的最长时间（以秒为单位）。典型值为 32 或 64（2⁵ 或 2⁶）秒。请选择最适合您的用例的值。
• 将 deadline 替换为持续发送重试的秒数上限。请选择一个反映您的用例的值。例如，在对时间要求不高的持续集成/持续部署 (CI/CD) 流水线中，您可以将 deadline 设置为 300 秒（5 分钟）。

要重试的错误类型

对返回错误代码 500、502、503 或 504 的所有 IAM API 请求使用此重试策略。

（可选）您可以将此重试策略用于返回错误代码 404 的 IAM API 请求。IAM 读取最终一致；因此，资源在创建后可能不会立即显示，而这可能会导致 404 错误。

此外，针对返回错误代码 409 和状态 ABORTED 的所有 IAM API 请求，请使用此重试策略的修改版本。此类错误表示出现并发问题；例如，您可能尝试更新另一个客户端已覆盖的允许政策。对于此类错误，您应该始终使用引入了抖动的截断指数退避算法来重试请求的整个读取-修改-写入系列。如果仅重试写入操作，则请求将继续失败。

后续步骤

• 了解如何管理允许政策中的并发问题。
• 了解如何实现“读取-修改-写入”模式来更新允许政策。