一、计数器（固定窗口）算法
在指定周期内累加访问次数，当访问次数达到设定的阈值时，触发限流策略，当进入下一个时间周期时进行访问次数的清零。
限定每一分钟能够处理的总的请求数为100，在第一个一分钟内，一共请求了60次。接着到第二个一分钟，counter又从0开始计数，在一分半钟时，已经达到了最大限流的阈值，这个时候后续的所有请求都会被拒绝。这种算法可以用在短信发送的频次限制上，比如限制同一个用户一分钟之内触发短信发送的次数。
存在的问题：临界问题
这种算法存在一个临界问题，这种算法针对的是固定周期的累加访问次数，但是如果服务器需要做到的是限制每个一分钟内的访问量，这种算法显然就不适用了，因为计数器算法无法限制每隔一段时间内的访问量均不超过阈值。
在第一分钟的0：58和第二分钟的1：02这个时间段内，分别出现了100个请求，整体来看就会出现4秒内总的请求量达到200，超出了设置的阈值。
二、滑动窗口算法
滑动窗口算法是将时间周期分为N个小周期（窗口），分别记录每个小周期内访问次数，然后根据时间将窗口往前滑动并删除过期的小时间窗口。最终只需要统计滑动窗口范围内的所有小时间窗口总的计数即可。
将一分钟拆分为4个小时间窗口，每个小时间窗口最多能够处理25个请求。并且通过虚线框表示滑动窗口的大小（当前窗口的大小是2，也就是在这个窗口内最多能够处理50个请求）。同时滑动窗口会随着时间往前移动，比如前面15s结束之后，窗口会滑动到15s～45s这个范围，然后在新的窗口中重新统计数据。
由此可见，当滑动窗口的格子划分的越多，那么滑动窗口的滚动就越平滑，限流的统计就会越精确。此算法可以很好的解决固定窗口算法的临界问题。
三、漏桶限流算法
漏桶限流算法的主要作用是控制数据注入网络的速度，平滑网络上的突发流量。
在漏桶算法内部同样维护一个容器，这个容器会以恒定速度出水，不管上面的水流速度多快，漏桶水滴的流出速度始终保持不变。访问请求到达时直接放入漏桶，如当前容量已达到上限（限流值），则进行丢弃（触发限流策略）。漏桶以固定的速率进行释放访问请求（即请求通过），直到漏桶为空。实际上消息中间件就使用了漏桶限流的思想，不管生产者的请求量有多大，消息的处理能力取决于消费者。
限流场景
在漏桶限流算法中，存在以下几种可能的情况：
• 请求速度大于漏桶流出水滴的速度：也就是请求数超出当前服务所能处理的极限，将会触发限流策略。
• 请求速度小于或者等于漏桶流出水滴的速度，也就是服务端的处理能力正好满足客户端的请求量，将正常执行。
漏桶限流算法和令牌桶限流算法的实现原理相差不大，最大的区别是漏桶无法处理短时间内的突发流量，漏桶限流算法是一种恒定速度的限流算法。
四、令牌桶限流算法
令牌桶是网络流量整形（Traffic Shaping）和速率限制（Rate Limiting）中最常使用的一种算法。对于每一个请求，都需要从令牌桶中获得一个令牌，如果没有获得令牌，则需要触发限流策略。
系统会以一个恒定速度（r tokens/sec）往固定容量的令牌桶中放入令牌，如果此时有客户端请求过来，则需要先从令牌桶中拿到令牌以获得访问资格。
令牌桶的另外一个好处是可以方便的改变速度. 一旦需要提高速率,则按需提高放入桶中的令牌的速率. 一般会定时(比如100毫秒)往桶中增加一定数量的令牌, 有些变种算法则实时的计算应该增加的令牌的数量。
限流场景
假设令牌生成速度是每秒10个，也就等同于QPS=10，此时在请求获取令牌的时候，会存在三种情况：
• 请求速度大于令牌生成速度：那么令牌会很快被取完，后续再进来的请求会被限流。
• 请求速度等于令牌生成速度：此时流量处于平稳状态。
• 请求速度小于令牌生成速度：说明此时系统的并发数并不高，请求能被正常处理。
由于令牌桶有固定的大小，当请求速度小于令牌生成速度时，令牌桶会被填满。所以令牌桶能够处理突发流量，也就是在短时间内新增的流量系统能够正常处理，这是令牌桶的特性。
参考文献
链接：https://www.jianshu.com/p/7815852d6c95
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。