API 的可靠性取决于确定您的容量和资源，从而满足应用程序随时间推移而不断变化的需求。因此您需要试图了解并预测使用情况，然后管理请求速率，以防止在使用高峰期出现服务过多而瘫痪的情况。
在亚马逊销售伙伴 API (Amazon Selling Partner API) 中，使用令牌存储桶算法可以限制请求速率。该算法基于一个包含令牌的存储桶类比，其中每个令牌均可交换以发出请求。令牌会按照设定的每秒速率自动添加到存储桶，直到达到存储桶的最大值。最大值也称为突增速率。每发出一个请求，存储桶就会减去一个令牌。如在发出请求时，存储桶为空且无可用令牌，则会触发限制。受限的请求会导致错误响应。
使用方案
亚马逊销售伙伴 API (Amazon Selling Partner API) 操作具有对应的使用方案，这些方案指明速率限制。您可以在 API 参考文档中进行查看。使用方案的定义如下：
- 速率 – 每秒添加到令牌存储桶的请求数，可用于提交请求且不会受限。如果您在长时间内持续调用，请保持低于此速率以免请求受限。
- 突增 – 令牌存储桶的最大值。此数值也表示在假定可填满令牌存储桶的情况下，您在一段时间内建立并同时提交的最大请求数。
动态使用方案
这项新功能可根据业务的长期需求自动调整速率限制。
动态使用方案能够根据每个销售伙伴的当前和历史业务需求进行自动调整。采用多种措施作为规则，以动态调整速率限制。也就是说，对于采用动态使用方案的任何亚马逊销售伙伴 API (Amazon Selling Partner API) 操作，您都可以预测其速率限制的变更。您可以按照 API 参考文档中发布的默认速率规划应用程序。但是，由于动态使用方案旨在根据时间的推移不断调整限制，因此速率在日后会有所变化。当您向亚马逊销售伙伴 API (Amazon Selling Partner API) 操作提交请求时，该操作的当前速率限制将发回至 x-amzn-RateLimit-Limit 响应标头。
与亚马逊商城网络服务（亚马逊 MWS）的比较
与亚马逊 MWS 相比，动态使用方案旨在减少限制。当前的亚马逊 MWS 实行统一的速率限制，不考虑业务规模或随时间而变化的业务需求。借助亚马逊销售伙伴 API (Amazon Selling Partner API) 中的动态使用方案，您可以脱离“一刀切”的速率限制，转而使用这个强调根据业务情况和随时间而变化的业务需求，为每个销售伙伴调整速率限制的灵活方案。
主要的设计改进如下：
- 动态使用方案会根据不断变化的业务需求调整速率限制。为每个销售伙伴设置了不同的速率限制。
- 动态使用方案可自动调整速率以改善流量性能。
常见问题
通用
我的应用程序应如何处理 429 响应？
429 是一个可重试的状态代码。请再试一次，但重复受限的请求需要采取后退措施。请参阅 x-amzn-RateLimit-Limit 响应标头，查看速率限制是否与您的预期不同。
如何测试应用程序的使用方案？
亚马逊销售伙伴 API (Amazon Selling Partner API) 测试沙箱采用的是生产使用方案。您可以在沙箱中查看与生产过程相同的速率限制行为。
我的应用程序可以完全避免受到限制吗？
不可以。您无法控制的任何因素都可能导致出现少量的瞬态 429 代码。此结果属于预料之中，应在您的应用程序代码中加以考虑。
如果我的应用程序一直受到限制，该怎么办？
如果您的应用程序始终为受限状态，您的调用模式可能需要进一步优化。例如：
- 降低调用频率，以符合您的速率限制。
- 通过轮询机制推送通知。
- 尽可能使用批量 API。
对于我的使用实例来说，一次操作的速率限制过低。可以提高限制吗？
我们的目标是设置适当限制，且高效的调用模式在理想情况下绝不会受到限制。如果您认为我们未正确考虑您的使用实例，烦请提交一个支持 TT 予以告知。
当我获得更多授权时，我应用程序的受限频率会增加吗？
不会。所有使用方案都是根据应用程序-销售伙伴成对提供的，因此您的吞吐量会随客户自然增长。
速率限制是否会改变？
我们可以随时提高速率限制。如果我们降低了 API 参考文档中发布的速率限制，我们会提前告知您，以便您在更改生效之前可以及时更新和测试您的应用程序。
动态使用方案的速率限制（如下所述）会根据业务情况自动调高或调低。
动态使用方案
动态使用方案的总体目标是什么？
根据历史使用情况，我们注意到同类使用方案在某些情况下负载过大，而且更糟糕的是，对于其他情况而言，却负载不足。动态使用方案的目标是利用给定调用的已知背景为任何情况设置适当限制。
影响动态使用方案的因素有哪些？
一般来说，速率限制由销售伙伴业务的类型、规模和行为所决定。
特定使用方案的相关限制会多久更改一次？
我们的目标是防止对限制频繁地进行破坏性更改。通常情况下，在观察到有需求时就会立即更改限制。
我应该如何给我的应用程序编码以适应动态限制？
以下是一些关于动态速率限制的良好应用程序行为的建议。
- 读取速率限制标头。
- 不要对计时器进行硬编码。
- 自然而然地针对事件进行编码，而非循环运行。如果您照做，根本不需要计时器。在重新定价的示例中，根据价格通知更新价格，而非每 n 秒更新一次价格。
亚马逊销售伙伴 API (Amazon Selling Partner API) 中有哪些部分需要使用动态使用方案？
用于订单的销售伙伴 API。
为什么不是所有操作都支持动态使用方案？
我们正在努力研究中\！
更多：
