速率限制

如果亚马逊广告 API 在指定时段收到的请求过多，则会发生速率限制，有时也称为节流 (throttling)。

若出现这种情况，您将收到代码为 429 的响应。该响应包含一个 Retry-After 标头。Retry-After 值是您在提交另一个 API 调用之前应等待的秒数。速率限制根据整个系统的负载情况动态发生。

避免报告的速率限制

与商品推广报告 API、展示型推广报告 API 和 品牌推广报告 API 关联的速率限制取决于报告生成队列的规模。这些限制是根据每个区域确定的，包含多个限制等级，对应于给定区域的当前报告队列规模。较高的利用率时间段和较高的报告队列规模会导致较低的速率限制。较低的利用率时间段会导致较高的速率限制，接受的报告生成请求数量也会增加。

根据区域的不同，每天的较高利用率时间段可能不同。如果您遇到较低的速率限制并且 429 HTTP 响应代码的出现次数较高，亚马逊建议您在一天中分散发出报告生成请求。例如，执行报告回填 (backfill)，或在一天中以较小的增量请求早期数据时间段，并且一般避免发送大批量的报告生成请求。

亚马逊还建议使用指数退避 (exponential backoff) 来应对多次出现 429 HTTP 响应代码的情况。

注意

动态速率限制不太可能在短时间内发生变化。因此，应为报告的生成选择更长的退避期。

避免所有其他 API 调用的速率限制

亚马逊广告 API 中的速率限制是动态的，基于系统负载。如果您遇到频繁的速率限制，可以按照以下优秀实践降低速率限制：

使用带有指数退避功能的重试逻辑

如果调用亚马逊广告 API 失败，则错误属于以下三类之一：

1. **服务器错误：**HTTP 响应是一个 500 级别代码，表示 API 服务存在问题。
2. **节流错误：**HTTP 响应为 429，这是一种管理上强制实施的限制，限制了允许的 API 调用频率。
3. **客户端错误：**此 HTTP 响应是除 429 以外的 400 级别代码，表示请求存在问题。请先调查请求中的错误，然后重试。

通常，对于收到服务器错误或节流错误的请求，您应当重试。重试请求时，请使用指数退避算法。指数退避背后的理念是指：在连续错误响应的重试之间使用越来越长的等待时间。例如，当收到 429 或 5xx 错误时，您的应用程序可能会退避 2 秒钟然后重试。如果继续收到错误，则退避 4 秒钟，然后重试。如果仍然收到错误，则退避 8 秒钟，然后重试，依此类推。您应该实施最大延迟间隔以及重试逻辑的最大重试次数。

有关此类方案的详细信息，请参阅 AWS 参考指南中的错误重试和指数退避。

如果扩展属性不必要，请勿调用“list extended data”（列出扩展数据）操作

这些调用的负荷是标准调用的 5 倍，达到节流限制，而且处理起来相当消耗资源。扩展数据的 List 操作和标准 List 操作列表之间的唯一区别在于，扩展调用可提供实体的状态。除非您特别需要了解实体的状态，否则请避免调用扩展数据操作。

不要对所有实体调用 List 操作

要列出指定级别的所有实体需要大量的 API 调用，而且此操作无法很好地扩展。对于进行数千次 List 操作，更好的替代方法是请求快照并解析结果。

要了解每种广告类型的快照规范，请参阅：

• 品牌推广快照资源
• 展示型推广快照资源
• 商品推广快照资源

避免在使用量高峰时段提出报告请求。

商品推广、展示型推广和品牌推广报告接口中的速率限制随使用量级别而变化。在使用量高峰时段降低速率限制，在使用量低峰时段提高速率限制。在接口区域级别确定使用量级别。亚马逊鼓励用户在一天中分散处理报告创建请求，例如在一天中分时段提取早期数据。