Usage Plans and Rate Limits in the Selling Partner API

AmazonSPAPI

# 销售伙伴 API 中的使用计划和费率限制

API的可靠性取决于你的容量和资源的大小,以满足应用程序随着时间变化的需求。这意味着要尝试了解和预测使用情况,然后管理请求的频率,以防止在使用高峰期使服务不堪重负。

在销售伙伴API中,使用令牌桶算法 (opens new window)对请求进行速率限制。该算法是基于一个包含代币的桶的类比,每个代币可以被交换来进行请求。代币被自动添加到桶中,使用设定的每秒速度,直到达到桶的最大尺寸。最大尺寸也被称为突发率。每个请求都会从桶中减去一个令牌。当一个请求被提出时,由于桶是空的,没有可用的令牌,就会发生节流。一个节流的请求会导致一个错误的响应。

# 使用计划

Selling Partner API操作有相关的使用计划,规定了速率限制。你可以在API参考文档中找到这些。使用计划的定义是。

  • 速率 - 每秒的请求数,这些请求被添加到令牌桶中,因此可以用来提交请求,而不会遇到节流。如果你在很长一段时间内连续进行调用,保持在这个速率以下将帮助你避免节流请求。
  • 爆发 - 代币桶可以达到的最大尺寸。这也代表了你可以随着时间的推移建立起最大的请求数量,然后同时提交,假设令牌桶已满。

# 标准使用计划

大多数销售伙伴的API都受标准使用计划的制约。对于标准使用计划,所有调用者的费率限制都是静态的,并且基于我们对每个API操作的预期调用模式。每个Selling Partner API操作的默认使用计划费率都公布在该API部分的API参考中。API操作的调用者应该收到默认费率所显示的吞吐量。如果销售伙伴的业务需求需要更高的吞吐量,如果他们被亚马逊授予覆盖权,他们可能会看到比默认速率和突发值更高的数据。

如果你发现默认费率不足以满足你的使用情况,请向我们的开发人员支持团队开具支持票,申请覆盖。

# 动态使用计划

动态使用计划功能仅适用于**订单的销售伙伴API。

动态使用计划是根据每个销售伙伴的当前和历史业务需求,自动调整该业务。API参考文件中公布的默认费率限制可以用来规划你的应用。然而,由于动态使用计划的目的是随着时间的推移合理调整这些限制,费率可能会改变。

各种销售伙伴的业务指标会影响费率调整。这些只是*业务指标,不包括API请求的历史数量。费率不会因为一个应用程序更频繁地发送API请求而动态地增加。

如果你发现动态费率仍不足以满足你的使用情况,请向我们的开发人员支持团队开具支持票,申请覆盖。

# x-amzn-RateLimit-Limit响应头

当你提交对销售伙伴API操作的请求时,该操作的当前费率限制将在x-amzn-RateLimit-Limit响应头中返回,在尽力而为的基础上,只针对HTTP状态代码20x、400和404。在某些情况下,我们请求、检索和提供速率限制的尽力尝试本身可能失败。这可能是由于随机的网络错误,我们的请求尝试被扼杀,或其他难以预测的问题。当这种情况发生时,我们不会让对销售伙伴API操作的其他有效请求失败。相反,我们将返回没有标头的响应。

这意味着你不能依赖响应中x-amzn-RateLimit-Limit头的存在。相反,在尝试使用速率限制值之前,应检查是否存在该头信息。

x-amzn-RateLimit-Limit不应该出现在节流、未经授权或未经认证的请求的响应中。

# 常见的问题

# 一般问题

# 对我的使用情况来说,一个操作的速率限制太低了。能否提高限制?

我们的目标是合适的限制,理想情况下,有效的呼叫模式不应受到限制。如果你认为你有一个我们没有适当考虑的用例,请让我们知道,请在我们的开发者支持团队中开一个支持票。

# 我的应用程序应该如何处理429响应?

429是一个可重试的状态代码。请随意再试,但重复的节流请求需要采取回避策略。请参考x-amzn-RateLimit-Limit响应头,如果有的话,看看速率限制是否与你的预期不同。

# 我如何测试我的应用程序与它的使用计划?

你可以使用销售伙伴API沙盒测试429错误处理。然而,你不能用沙盒测试速率限制。这是因为虽然生产中的操作可以有不同的费率,但所有的沙盒操作都有相同的费率。你可以在每个操作的x-amzn-RateLimit-Limit响应头中看到你分配的使用率,如果有的话。

# 我的应用程序可以完全避免被节流吗?

任何超出你控制范围的因素都可能导致少量的瞬时429s。这是预期的,应该在你的应用程序代码中加以说明。

# 如果我的应用程序被持续节流,我应该怎么做?

如果你的应用程序被持续节流,这可能意味着你的调用模式可以进一步优化。比如说。

  1. 根据你的速率限制,减少呼叫频率。

  2. 依靠推送通知而不是轮询机制。

  3. 使用可用的批处理API,或以其他方式尝试用较少的调用做更多的事情。例如,使用Feeds (opens new window)Reports (opens new window) API,你可以用相对较少的调用来发送或检索大量的信息(即成批的信息)。一般来说,对照API中的操作检查你的调用模式,看看你是否可以用较少的调用完成同样的工作。

# 当我获得更多的授权时,我的应用程序是否会更频繁地被节流?

不会。所有的使用计划都是针对应用-销售伙伴对的,因此你的吞吐量会随着你的客户自然增长。

# 费率限制会改变吗?

我们可以在任何时候提高费率限制。如果我们降低了API参考文件中公布的费率限制,我们会提前通知您,以便您有时间在变化生效前更新和测试您的应用程序。

动态使用计划的费率限制(如下所述)会根据业务情况自动调高或调低。

# 动态使用计划

# 如果我的应用程序不断被节流,我的费率限制会增加吗?

费率是基于销售伙伴的业务指标。如果一个应用程序被持续节流,这可能意味着你的呼叫模式与分配给该销售伙伴的费率限制不一致。 请参阅 如果我的应用程序被持续节流,我该怎么办? 另请参阅 对我的用例而言,一项操作的速率限制太低。可以增加限制吗?

# 动态使用计划的总体目标是什么?

从历史上看,我们已经观察到,同质化的使用计划对于某些情况来说规模过大,更糟糕的是,对于其他情况来说规模过小。动态使用计划的目标是利用特定呼叫的已知业务背景,为任何情况设置正确的限制。

# 什么因素影响动态使用计划?

一般来说,费率限制是由销售伙伴业务的类型、规模和行为决定的。

# 与特定使用计划相关的限额多久会改变?

我们的目标是防止频繁的、破坏性的限额变化。一般来说,一旦我们发现销售伙伴账户中的业务指标发生有意义的变化,就会立即改变限额。

# 我应该如何为我的应用程序编码以尊重动态限制?

以下是一些关于动态费率限制方面的良好应用行为的建议。

  1. 读取x-amzn-RateLimit-Limit头,如果有的话。

  2. 不要硬编码定时器。

  3. 对事件进行自然编码,而不是在一个循环上运行。如果你这样做,你就根本不需要定时器。在重新定价器的例子中,根据价格通知来更新价格,而不是每隔n秒就更新一次。

Last Updated: 2022/10/11 下午9:45:34