亚马逊 MWS 开发者指南 漏桶算法

流量控制与令牌桶算法｜James Pan's Blog  https://blog.jamespan.me/2015/10/19/traffic-shaping-with-token-bucket

服务治理---限流（令牌桶算法） - googlemeoften - 博客园  http://www.cnblogs.com/googlemeoften/p/6020718.html

一年一度的「双 11」又要到了，阿里的码农们进入了一年中最辛苦的时光。各种容量评估、压测、扩容让我们忙得不可开交。洛阳亲友如相问，就说我搞双十一。

如何让系统在汹涌澎湃的流量面前谈笑风生？我们的策略是不要让系统超负荷工作。如果现有的系统扛不住业务目标怎么办？加机器！机器不够怎么办？业务降级，系统限流！

正所谓「他强任他强，清风拂山岗；他横任他横，明月照大江」，降级和限流是大促保障中必不可少的神兵利器，丢卒保车，以暂停边缘业务为代价保障核心业务的资源，以系统不被突发流量压挂为第一要务。

集团的中间件有一个不错的单机限流框架，支持两种限流模式：控制速率和控制并发。限流这种东西，应该是来源于网络里面的「流量整型」，通过控制数据包的传输速率和时机，来实现一些性能、服务质量方面的东西。令牌桶是一种常见的流控算法，属于控制速率类型的。控制并发则相对要常见的多，比如操作系统里的「信号量」就是一种控制并发的方式。

在 Wikipedia 上，令牌桶算法是这么描述的：

1. 每秒会有 r 个令牌放入桶中，或者说，每过 1/r 秒桶中增加一个令牌
2. 桶中最多存放 b 个令牌，如果桶满了，新放入的令牌会被丢弃
3. 当一个 n 字节的数据包到达时，消耗 n 个令牌，然后发送该数据包
4. 如果桶中可用令牌小于 n，则该数据包将被缓存或丢弃

令牌桶控制的是一个时间窗口内的通过的数据量，在 API 层面我们常说的 QPS、TPS，正好是一个时间窗口内的请求量或者事务量，只不过时间窗口限定在 1s 罢了。

现实世界的网络工程中使用的令牌桶，比概念图中的自然是复杂了许多，「令牌桶」的数量也不是一个而是两个，简单的算法描述可用参考中兴的期刊^1或者 RFC。

假如项目使用 Java 语言，我们可以轻松地借助 Guava 的 RateLimiter 来实现基于令牌桶的流控。RateLimiter 令牌桶算法的单桶实现，也许是因为在 Web 应用层面单桶实现就够用了，双筒实现就属于过度设计。

RateLimiter 对简单的令牌桶算法做了一些工程上的优化，具体的实现是 SmoothBursty。需要注意的是，RateLimiter 的另一个实现 SmoothWarmingUp，就不是令牌桶了，而是漏桶算法。也许是出于简单起见，RateLimiter 中的时间窗口能且仅能为 1s，如果想搞其他时间单位的限流，只能另外造轮子。

SmoothBursty 积极响应李克强总理的号召，上个月的流量没用完，可以挪到下个月用。其实就是 SmoothBursty 有一个可以放 N 个时间窗口产生的令牌的桶，系统空闲的时候令牌就一直攒着，最好情况下可以扛 N 倍于限流值的高峰而不影响后续请求。如果不想像三峡大坝一样能扛千年一遇的洪水，可以把 N 设置为 1，这样就只屯一个时间窗口的令牌。

RateLimiter 有一个有趣的特性是「前人挖坑后人跳」，也就是说 RateLimiter 允许某次请求拿走超出剩余令牌数的令牌，但是下一次请求将为此付出代价，一直等到令牌亏空补上，并且桶中有足够本次请求使用的令牌为止[^2]。这里面就涉及到一个权衡，是让前一次请求干等到令牌够用才走掉呢，还是让它先走掉后面的请求等一等呢？Guava 的设计者选择的是后者，先把眼前的活干了，后面的事后面再说。

[^2]: How is the RateLimiter designed, and why?

当我们要实现一个基于速率的单机流控框架的时候，RateLimiter 是一个完善的核心组件，就仿佛 Linux 内核对 GNU 操作系统那样重要。但是我们还需要其他的一些东西才能把一个流控框架跑起来，比如一个通用的 API，一个拦截器，一个在线配置流控阈值的后台等等。

流控算法 - YDDMAX - 博客园  http://www.cnblogs.com/YDDMAX/p/5680041.html

w

http://docs.developer.amazonservices.com/zh_CN/dev_guide/DG_Throttling.html

要想正常使用亚马逊商城网络服务（亚马逊 MWS），就需要了解相关限制。限制是指对特定时间内提交的请求数量进行限制的过程。如果您要提交库存上传数据或下载订单报告，则为一个请求。限制功能可以避免网络服务遭受过量请求的不利影响，确保所有授权的开发者均可访问网络服务。

亚马逊 MWS 采用若干种漏桶算法来衡量网络服务状态并执行相关限制。该算法的依据是漏桶假设，即漏桶中的水以一定的速率从桶底的小孔中漏出。可以间歇性地向桶中注水，但如果一次注水太多，或注水的频率过高，水就会溢出桶外。

要将这个假设应用于亚马逊 MWS，设想漏桶的容积代表最大请求限额，即您每次可以提交的最大请求数量。桶底的小孔代表恢复速率，即提出新的请求前需要的恢复时间。因此，如果您一次提交了太多请求，漏桶中的水就会溢出，而在亚马逊 MWS 中，就会触发限制。将漏桶注满后，在继续注水前还需要等一会儿，因为水从桶中漏出的速率是一定的。同理，达到最大请求限额后，再过多久才能提交更多请求则取决于恢复速率，即提出新的请求前需要等待的时间。

控制亚马逊 MWS 限制功能的三个值定义如下：

• 请求限额 - 每次允许提交而不会触发限制的请求数量。请求限额会随着提交请求的增加而减少，并以还原速率增加。请求将以每一个亚马逊卖家账号与亚马逊 MWS 开发者账号的配对做统计计算。
• 还原速率（也称恢复速率）- 请求限额随着时间增加，直到达到最大请求限额的速率。
• 最大请求限额（也称溢出速率）- 请求限额可以达到的最大数值。

要应用这些知识，请思考以下示例。设想您要使用 SubmitFeed 操作提交 25 个库存更新上传数据。SubmitFeed 操作的最大请求限额为 15，恢复速率为每 2 分钟 1 个请求。如果您要提交 25 个上传数据请求，而在达到 15 个请求之后，您的请求将被限制，其余 10 个上传数据请求则必须等到请求限额还原后再重新提交。由于还原速率是每两分钟一个请求，因此要过 20 分钟才能提交剩余的 10 个上传数据请求。因此，与其提交所有请求而触发限制，然后重新提交被限制的请求，不如设定流程自动化模式，递增式地提交上传数据请求。

例如，您可以提交 10 个上传数据请求（最初 25 个上传数据中的 10 个），这样请求限额还剩 5 个余额。然后，您可以等 10 分钟，此时还原速率已将请求限量增加为 10（每两分钟一个请求，10 分钟即增加了 5 个新请求限量）。这样，您就可以再提交 10 个上传数据请求了。至于剩余的 5 个上传数据请求，您可以再等十分钟再提交。如果一切顺利，您只需 20 分钟左右即可提交全部 25 个库存上传数据。

您应该考虑自动化提交请求，并做好应急准备，以应对达到最大请求限额而触发限制，或网络服务流量过高的情况，此时应减少提交请求的数量，并重新提交失败的请求。