# 销售伙伴 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。这是预期的，应该在你的应用程序代码中加以说明。
# 如果我的应用程序被持续节流，我应该怎么做？
如果你的应用程序被持续节流，这可能意味着你的调用模式可以进一步优化。比如说。
根据你的速率限制，减少呼叫频率。
依靠推送通知而不是轮询机制。
使用可用的批处理API，或以其他方式尝试用较少的调用做更多的事情。例如，使用Feeds (opens new window)和Reports (opens new window) API，你可以用相对较少的调用来发送或检索大量的信息（即成批的信息）。一般来说，对照API中的操作检查你的调用模式，看看你是否可以用较少的调用完成同样的工作。
# 当我获得更多的授权时，我的应用程序是否会更频繁地被节流？
不会。所有的使用计划都是针对应用-销售伙伴对的，因此你的吞吐量会随着你的客户自然增长。
# 费率限制会改变吗？
我们可以在任何时候提高费率限制。如果我们降低了API参考文件中公布的费率限制，我们会提前通知您，以便您有时间在变化生效前更新和测试您的应用程序。
动态使用计划的费率限制（如下所述）会根据业务情况自动调高或调低。
# 动态使用计划
# 如果我的应用程序不断被节流，我的费率限制会增加吗？
费率是基于销售伙伴的业务指标。如果一个应用程序被持续节流，这可能意味着你的呼叫模式与分配给该销售伙伴的费率限制不一致。 请参阅 如果我的应用程序被持续节流，我该怎么办？ 另请参阅 对我的用例而言，一项操作的速率限制太低。可以增加限制吗？。
# 动态使用计划的总体目标是什么？
从历史上看，我们已经观察到，同质化的使用计划对于某些情况来说规模过大，更糟糕的是，对于其他情况来说规模过小。动态使用计划的目标是利用特定呼叫的已知业务背景，为任何情况设置正确的限制。
# 什么因素影响动态使用计划？
一般来说，费率限制是由销售伙伴业务的类型、规模和行为决定的。
# 与特定使用计划相关的限额多久会改变？
我们的目标是防止频繁的、破坏性的限额变化。一般来说，一旦我们发现销售伙伴账户中的业务指标发生有意义的变化，就会立即改变限额。
# 我应该如何为我的应用程序编码以尊重动态限制？
以下是一些关于动态费率限制方面的良好应用行为的建议。
读取
x-amzn-RateLimit-Limit头，如果有的话。不要硬编码定时器。
对事件进行自然编码，而不是在一个循环上运行。如果你这样做，你就根本不需要定时器。在重新定价器的例子中，根据价格通知来更新价格，而不是每隔n秒就更新一次。