本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 限制 Amazon Route 53 API 请求
**重要**
亚马逊 Route 53 更新了其 API 限制行为。此更新包括增加每秒请求数限制和引入基于变化的限制。本页详细描述了更新的限制。
Amazon Route 53 对每个账户的 API 请求进行限制，以维护服务稳定性并确保所有客户的公平使用。Route 53 适用两个独立限制：
+ **请求速率：**每秒 API 请求数。
+ **变更吞吐量：**修改 DNS 数据的 API 操作汇总的每秒单个 DNS 记录更改次数。
请求可以受到任一限制的限制。当请求受到限制时，亚马逊 Route 53 会返回 HTTP 400 错误 () `Bad request`。响应标头还包括一个其值为 `Throttling` 的 `Code` 元素，以及一个值为 `Rate exceeded` 的 `Message` 元素。
## 如何应用节流
亚马逊 Route 53 使用代币存储桶算法。每个限额都有一个存储桶，可容纳最大数量的代币。每次请求（请求速率限制）或每次更改（更改吞吐量限制）都会从适用的存储桶中移除令牌。水桶每秒以固定速率重新装满，直至最大容量。如果充值代币在存储桶已满时到达，Route 53 会将其丢弃。
两个值描述了每个存储桶：
+ **存储桶的最大容量**是您的爆发量：存储桶已满时 Route 53 可以同时吸收的请求或更改数量。
+ **存储桶充值率**是您的持续速率：您可以无限期保持的每秒请求或更改次数。
您可以在添加代币时使用充值；您无需等待存储桶完全充值。
## 请求费率代币存储桶大小和充值率
Route 53 在两个级别上应用请求速率限制：
+ **账户级别：来自您账户**的所有亚马逊 Route 53 API 请求均来自一个存储桶。
+ **账户和操作级别：**每个 API 操作也有自己的存储桶。
请求消耗两个存储桶中的令牌，如果其中一个存储桶为空，则请求会受到限制。以下操作具有不同的默认请求速率限制。
**每个 API 操作的请求速率限制**
| API 操作 | 存储桶最大容量 | 存储桶重填速率 |
| --- | --- | --- |
| 所有 Amazon Route 53 API 操作合并（账户级别） | 50 | 10 |
| 下面未列出的任何 API 操作（每个操作的默认值） | 50 | 10 |
| AssociateVPCWithHostedZone | 20 | 5 |
| ChangeCidrCollection | 40 | 5 |
| CreateCidrCollection | 40 | 5 |
| CreateHealthCheck | 50 | 0.5 |
| CreateHostedZone | 40 | 2 |
| CreateReusableDelegationSet | 40 | 2 |
| CreateTrafficPolicyInstance | 1 | 1 |
| DeleteCidrCollection | 40 | 5 |
| DeleteHealthCheck | 15 | 3 |
| DeleteHostedZone | 40 | 5 |
| DeleteReusableDelegationSet | 40 | 5 |
| DeleteTrafficPolicyInstance | 1 | 1 |
| DisassociateVPCFromHostedZone | 10 | 5 |
| GetHealthCheckLastFailureReason | 4 | 1 |
| GetHealthCheckStatus | 4 | 1 |
| UpdateHealthCheck | 50 | 5 |
| UpdateTrafficPolicyInstance | 1 | 1 |
有关亚马逊 Route 53 API 操作的完整列表，请参阅*亚马逊 Route 53 API 参考[中的](https://docs.aws.amazon.com/Route53/latest/APIReference/API_Operations_Amazon_Route_53.html)操作*。
### `CreateHealthCheck` 请求
您可以每隔 2 秒每个 AWS 账户提交一个 `CreateHealthCheck` 请求。这相当于上表中显示的每秒 0.5 个请求的重新填充率。
## 更改吞吐量限制
除请求速率限制外，修改 DNS 数据的 API 操作还受变更吞吐量限制的约束。此限制使用单独的代币存储桶，该存储桶的耗尽基于请求进行的 DNS 记录更改的次数，而不是请求的数量。更改吞吐量受每个 API 操作的限制 AWS 账户，而不是每个 API 操作的限制。以下所有操作均来自一个存储桶，该存储桶的最大容量为 1,500 次更改（爆发），并以每秒 100 次更改的速度重新填充（持续）。
更改的计算方式如下：
**每次操作消耗的代币**
| 操作 | 消耗的代币 |
| --- | --- |
| ChangeResourceRecordSets | 每人 1 个CREATE，每个 1 个DELETE，每个 2 个 UPSERT |
| AssociateVPCWithHostedZone | 2 |
| DisassociateVPCFromHostedZone | 2 |
| CreateHostedZone | 2 |
| DeleteHostedZone | 2 |
所有其他 Amazon Route 53 API 操作均不消耗变更吞吐量令牌，并且仅受请求速率的限制。
**示例：**您可以提交包含 1,000 个更改（一次突发）的单个请求，这将消耗 1,000 个令牌。爆发后，水桶以每秒 100 个代币的速度充满。如果您继续每秒提交 100 次更改，则可以无限期地保持该速率。如果您尝试维持每秒 500 次更改，则存储桶将耗尽，后续请求将受到限制，直到其重新填满。
## 监控 API 节流
您可以通过观察应用程序日志中的 HTTP 400 响应或通过 CloudWatch 指标跟踪 API 使用情况来监控亚马逊 Route 53 API 的使用情况。当您收到限制错误时，您的请求超过了前面部分中描述的限制之一。
## 重试和指数回退
当您轮询或重试 API 请求时，我们建议使用指数退避算法来计算请求之间的休眠间隔。指数退避会逐渐延长重试之间的等待时间，以获得连续的错误响应。实现最大延迟间隔和最大重试次数，并考虑添加抖动（随机延迟）以防止连续碰撞。有关更多信息，请参阅构建器库[中的](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)超时、重试和使用抖动进行退避。 AWS
每个 AWS SDK 都实现自动重试逻辑，包括自适应重试模式，该模式可根据限制调整客户端请求速率。对于经常接近这些限制的工作负载，可以考虑启用自适应重试。有关更多信息，请参阅 *AWS SDKs and Tools Reference Guide* 中的 [Retry behavior](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)。
## 申请提高限制
您可以通过 AWS 支持请求提高 API 请求率或更改吞吐量限制。要申请加薪，请执行以下操作：
+ 打开[AWS 支持中心](https://console.aws.amazon.com/support/home)。
+ 创建案例并选择提高**服务限额**。
+ 对于**限制类型**，选择**路线 53 **。
+ 提供您的当前使用量和所需的限额。
## API 限制的最佳实践
+ **平衡请求速率与批量大小：**如果您受到请求速率限制的限制，请为每个请求发送更多更改。如果您受到变更吞吐量限制的限制，请降低总更改率。无论是非常小的批量还是非常大的批量本身都不是最佳选择。
+ **使用批处理实现原子性：单个`ChangeResourceRecordSets`请求中的**所有更改都是以原子方式应用的，因此它们一起成功或失败。
+ **随时间推移分散更改：在几秒钟内均匀**分配更改，而不是同时提交大批量更改。
+ **依靠突发来偶尔的峰值，而不是持续的吞吐量：**突发容量可以容纳合法的流量峰值；它不是持续的运营上限。
+ **使用指数退避重试：**当您收到 HTTP 400 响应时，延迟时间会随着每次尝试的增加而增加（参见）。[重试和指数回退](#retries-and-exponential-backoff)
+ **主动提高请求限额：**如果您预计工作负载会增长，请在达到限制之前申请提高请求上限（参见[申请提高限制](#requesting-a-limit-increase)）。
有关更广泛的亚马逊 Route 53 指南，请参阅[Amazon Route 53 的最佳实践](best-practices.md)。