限流算法之漏桶算法、令牌桶算法

限流

每一个API接口都是有访问上限的，当访问频率或者并发量超过其承受范围时候，咱们就必须考虑限流来保证接口的可用性或者降级可用性。即接口也须要安装上保险丝,以防止非预期的请求对系统压力过大而引发的系统瘫痪。

一般的策略就是拒绝多余的访问，或者让多余的访问排队等待服务，或者引流。

若是要准确的控制QPS，简单的作法是维护一个单位时间内的Counter，如判断单位时间已通过去，则将Counter重置零。此作法被认为没有很好的处理单位时间的边界，好比在前一秒的最后一毫秒里和下一秒的第一毫秒都触发了最大的请求数，将目光移动一下，就看到在两毫秒内发生了两倍的QPS。

限流算法

经常使用的更平滑的限流算法有两种：漏桶算法和令牌桶算法。

漏桶算法

漏桶(Leaky Bucket)算法思路很简单，水(请求)先进入到漏桶里，漏桶以必定的速度出水(接口有响应速率)，当水流入速度过大会直接溢出(访问频率超过接口响应速率)，而后就拒绝请求，能够看出漏桶算法能强行限制数据的传输速率。示意图以下:

可见这里有两个变量，一个是桶的大小，支持流量突发增多时能够存多少的水(burst)，另外一个是水桶漏洞的大小(rate)。

由于漏桶的漏出速率是固定的参数，因此，即便网络中不存在资源冲突(没有发生拥塞)，漏桶算法也不能使流突发(burst)到端口速率。所以，漏桶算法对于存在突发特性的流量来讲缺少效率。

令牌桶算法

令牌桶算法(Token Bucket)和 Leaky Bucket 效果同样但方向相反的算法，更加容易理解。

随着时间流逝，系统会按恒定1/QPS时间间隔(若是QPS=100,则间隔是10ms)往桶里加入Token(想象和漏洞漏水相反，有个水龙头在不断的加水)，若是桶已经满了就再也不加了。新请求来临时，会各自拿走一个Token，若是没有Token可拿了就阻塞或者拒绝服务。

令牌桶的另一个好处是能够方便的改变速度。一旦须要提升速率，则按需提升放入桶中的令牌的速率。通常会定时(好比100毫秒)往桶中增长必定数量的令牌，有些变种算法则实时的计算应该增长的令牌的数量。