API的可靠性取决于你的容量和资源的大小，以满足应用程序随时间变化的需求.这意味着尝试了解和预测使用情况，然后管理请求的频率，以防止在使用高峰期时服务不堪重负.
在销售伙伴API中，使用[token bucket算法对请求进行速率限制](https: //en.wikipedia.org/wiki/Token_bucket). 该算法是基于一个包含代币的桶的类比每一个代币都可以被交换来进行请求.代币被自动添加到桶中，使用设定的速率-per-second，直到达到桶的最大尺寸.最大尺寸也被称为突发速率.每个请求都会从桶中减去一个代币.当一个请求被提出时，由于桶是空的，没有可用的代币，就会发生节流.一个节流的请求导致一个错误响应
# 使用计划
Selling Partner API操作有相关的使用计划，指定了速率限制.你可以在API参考文档中找到这些计划.使用计划的定义是
-速率-每秒被添加到令牌桶中的请求数，因此可以用来提交请求而不经历节流.如果你在很长一段时间内连续进行调用，保持低于这个速率将帮助你避免节流请求. -突发 - 令牌桶可以达到的最大尺寸.这也代表了假设令牌桶满了，你可以随着时间的推移建立起最大的请求数量，然后同时提交.
# 标准使用计划
大多数销售伙伴的API受标准使用计划管理.在标准使用计划下，所有调用者的速率限制是静态的，并且基于我们对每个API操作的预期调用模式.每个销售伙伴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不应该出现在对节流的、未经授权的或未经认证的请求的响应中.
# 常见问题
# General
# 对我的使用情况来说，一个操作的速率限制太低了.能否提高限制？
我们的目标是正确的-大小的限制，目标是高效的调用模式，在理想情况下，永远不会被扼杀.如果你认为你有一个我们没有适当考虑的用例，请让我们知道，向我们的开发人员支持团队开一个支持票.
# 我的应用程序应该如何处理429响应？
429是一个重试-able状态代码.请随意再试，但重复的节流请求需要一个回退策略.请参考x-amzn-RateLimit-Limit响应头，如果有的话，看看速率限制是否与你的预期不同.
# 我怎样才能测试我的应用程序的使用计划？
你可以使用Selling Partner API沙盒测试429错误处理.但是，你不能用沙盒测试速率限制.这是因为虽然生产中的操作可以有不同的速率，但所有沙盒操作共享相同的速率.你可以在每个操作的x-amzn-RateLimit-Limit响应头中看到你分配的使用率，如果可用的话.
# 我的应用程序可以完全避免被节流吗？
不能.任何超出你控制范围的因素都可能导致少量的瞬时429s.这是预期的，应该在你的应用程序代码中加以考虑.
# 如果我的应用程序被持续节流，我应该怎么做？
如果你的应用程序一直处于节流状态，这可能意味着你的调用模式可以进一步优化.比如说
1.根据你的速率限制，减少呼叫频率.
2.依靠推送通知而不是轮询机制.
- 使用可用的批处理API，或以其他方式尝试用较少的调用做更多的事情. 例如，使用Feeds和[Reports](doc 报告-api-v2021-06-30-reference) API，你可以使用相对较少的调用次数来发送或检索大量的信息(i.e.成批的信息) 一般来说，对照API中的操作来检查你的调用模式，看看你是否可以用较少的调用次数完成同样的工作.
# 当我获得更多的授权时，我的应用程序是否会被更频繁地扼杀？
不会.所有的使用计划都是针对应用的-销售伙伴对，所以你的吞吐量会随着你的客户自然增长.
#6985## 费率限制会改变吗？
我们可以在任何时候提高费率限制.如果我们有一天降低了API参考文件中公布的费率限制，我们会提前沟通，让你有时间在变化生效前更新和测试你的应用程序.
动态使用计划的费率限制(讨论如下)根据业务情况自动调高或调低.
# 动态使用计划
# 如果我的应用程序不断被节流，我的费率限制会增加吗？
费率是基于销售伙伴的业务指标.如果一个应用程序被持续节流，这可能意味着你的呼叫模式与分配给该销售伙伴的费率限制不一致.参见如果我的应用程序被持续节流，我应该怎么办？ See also The rate limits for one operation are too low for my use case. Can the limit be increased? .
# 动态使用计划的总体目标是什么？
从历史上看，我们已经观察到，同质的使用计划在某些情况下是过大的，更糟糕的是，在其他情况下是过小的.动态使用计划的目标是利用特定呼叫的已知业务背景，为任何情况下的正确限制
# 哪些因素影响动态使用计划？
一般来说，费率限制是由销售伙伴业务的类型、规模和行为决定的.
# 与某一使用计划相关的限额多久会改变？
我们的目标是防止频繁地、破坏性地改变限额.一般来说，一旦我们发现销售伙伴账户中的业务指标发生有意义的变化，就会立即改变限额.
# 我应该如何为我的应用程序编码以尊重动态限额？
下面是一些关于动态费率限制方面的良好应用行为的建议.
- 读取
x-amzn-RateLimit-Limit头，如果有的话.
2.不要硬编码定时器.
3.针对事件自然编码，而不是在循环中运行.如果你这样做，你根本不需要计时器.在re-pricer的例子中，根据价格通知更新价格，而不是每n-seconds.