共计 862 个字符，预计需要花费 3 分钟才能阅读完成。
限流
每个 API 接口都是有访问上限的，当访问频率或者并发量超过其承受范围时候，我们就必须考虑限流来保证接口的可用性或者降级可用性。即接口也需要安装上保险丝, 以防止非预期的请求对系统压力过大而引起的系统瘫痪。
通常的策略就是拒绝多余的访问，或者让多余的访问排队等待服务，或者引流。
如果要准确的控制 QPS，简单的做法是维护一个单位时间内的 Counter，如判断单位时间已经过去，则将 Counter 重置零。此做法被认为没有很好的处理单位时间的边界，比如在前一秒的最后一毫秒里和下一秒的第一毫秒都触发了最大的请求数，将目光移动一下，就看到在两毫秒内发生了两倍的 QPS。
限流算法
常用的更平滑的限流算法有两种：漏桶算法和令牌桶算法。
漏桶算法
漏桶 (Leaky Bucket) 算法思路很简单，水 (请求) 先进入到漏桶里，漏桶以一定的速度出水(接口有响应速率)，当水流入速度过大会直接溢出(访问频率超过接口响应速率)，然后就拒绝请求，可以看出漏桶算法能强行限制数据的传输速率。示意图如下:
可见这里有两个变量，一个是桶的大小，支持流量突发增多时可以存多少的水(burst)，另一个是水桶漏洞的大小(rate)。
因为漏桶的漏出速率是固定的参数，所以，即使网络中不存在资源冲突 (没有发生拥塞)，漏桶算法也不能使流突发(burst) 到端口速率。因此，漏桶算法对于存在突发特性的流量来说缺乏效率。
令牌桶算法
令牌桶算法 (Token Bucket) 和 Leaky Bucket 效果一样但方向相反的算法，更加容易理解。
随着时间流逝，系统会按恒定 1 /QPS 时间间隔 (如果 QPS=100, 则间隔是 10ms) 往桶里加入 Token(想象和漏洞漏水相反，有个水龙头在不断的加水)，如果桶已经满了就不再加了。新请求来临时，会各自拿走一个 Token，如果没有 Token 可拿了就阻塞或者拒绝服务。
令牌桶的另外一个好处是可以方便的改变速度。一旦需要提高速率，则按需提高放入桶中的令牌的速率。一般会定时 (比如 100 毫秒) 往桶中增加一定数量的令牌，有些变种算法则实时的计算应该增加的令牌的数量。
