常见限流算法总结

引言

限流（Rate limiting）顾名思义就是限制流量，对请求或并发数进行限制，通过对流量的控制来保护系统不被压垮。虽然限流回导致部分客户无法使用系统，但相比于系统挂掉导致全部不可用，限流这种有损的解决方案还是可以接受的。限流的设计还能防止恶意请求流量、恶意攻击（如DOS攻击）。
本文将会分别介绍固定窗口计数器（Fixed window counter）、滑动窗口计数器（Sliding window counter）、漏桶算法（Leaky bucket）、令牌桶算法（Token bucket）这四种常见的限流算法。

固定窗口计数器

也叫计数器算法。通过一个支持原子操作的计数器来累计 1 秒内的请求次数，当 1 秒内计数达到限流阈值时触发拒绝策略。每过 1 秒，计数器重置为 0 开始重新计数。
优点：简单易实现
缺点：有临界问题，服务器限制每分钟的请求数为50，用户在0:59的时候发送50个请求，1:00的时候计数器重置了，用户在1:01的时候又发送了50个请求，该用户在一分钟内实际上发送了100个请求，但是固定窗口计数器算法无法拦截这样的请求。

滑动窗口计数器

针对固定窗口计数器的临界问题可以引出滑动窗口计数器。滑动窗口协议是传输层进行流控的一种措施，接收方通过通告发送方自己的窗口大小，从而控制发送方的发送速度，从而达到防止发送方发送速度过快而导致自己被淹没的目的。发送和接受方都会维护一个数据帧的序列，这个序列被称作窗口。发送方的窗口大小由接受方确定，目的在于控制发送速度，以免接受方的缓存不够大，而导致溢出，同时控制流量也可以避免网络拥塞。
滑动窗口协议的动画演示

演示地址中的滑动窗口大小为5，也就是将一个单位时间划分成了更小的5个单元，假设单位时间为1分钟，那么这里一小格就是12秒。每一小格一个自己独立的计数器，可以通过一个数组来存储这5个计数器，只要它们总和加起来不超过上限，请求就能被处理。滑动窗口算法以当前时间为截止时间，往前看一个单位的时间（这里为一分钟），计算一个单位的时间里请求数是否超过上限，也就是在1:00到1:12这个窗口里计算的请求数是0:12~1:00的总数。

滑动窗口计数器一定程度上可以解决固定窗口计数器的临界问题。

漏桶算法

漏桶算法的基本原理就是将请求放入一个桶（消息队列等）中，桶的底部匀速地将请求漏出来处理它，漏的速率固定，在这里就是1分钟/50个请求=0.02，也就是0.02分钟处理一个请求。桶的容量固定，当流入的请求超过桶的容量时就会触发拒绝策略。

应用场景：

令牌桶算法

令牌桶算法就是将令牌匀速放入桶中，当请求来了先从桶里获取一个令牌，获取成功则请求可以被处理，否则请求会被丢弃。

参考

https://en.wikipedia.org/wiki/Rate_limiting
https://en.wikipedia.org/wiki/Leaky_bucket
https://www.cnblogs.com/my_life/articles/14871604.html
https://segmentfault.com/a/1190000041548601