在开发高并发系统时，有三把利器用来保护系统：

• 缓存
• 降级
• 限流

那么何为限流呢？顾名思义，限流就是限制流量，那又有那些限流算法呢？

计数器算法

计数器限流算法，是指在指定的时间周期内累加访问次数,达到设定的需值时，触发限流策略。
下一个时间周期进行访问时，访问次数清零。此算法无论在单机还是分布式环境下实现都非常简单，使用redis的incr原子自增性,再结合key的过期时间，即可轻松实现。

• 设置一个计数器计数器，每当一个请求过来的时候，计数器就加1，如果计数器的值大于100并且该请求与第一个 请求的间隔时间还在1分钟之内，那么说明请求数过多；
• 如果该请求与第一个请求的间隔时间大于1分钟，且计数器的值还在限流范围内，那么就重置 计数器

这个算法实现简单，但是有一个十分致命的问题，那就是临界问题

临界问题

在第一个时间周期结束前的一秒进来100个请求，在第二个时间周期开始后一秒，进来100个请求，那么这个系统在两秒之内处理了200个请求，没有达到我们要求的限流

我们规定的是1分钟最多100个请求，也就是每秒大约1.7个请求，用户通过在时间窗口的重置节点处突发请求，可以瞬间超过我们的速率限制。用户有可能通过算法的这个漏洞，瞬间压垮我们的系统。

滑动时间窗口

为了应对计数器算法的临界问题，人们想出来滑动窗口算法。

• 在TCP网络通信协议中。就采用滑动时间窗口算法来解决网络拥堵问题。
• 滑动时间官口是将计数箱算法中的实际周期切分成多个小的时间窗口，分别在每个小的时间官口中记录访问次数。
• 然后根据时间将官口往前滑动并删吟过期的小时间会口。最终只需要统计滑动官口范围内的小时间离口的总的清求数即可。

整个红色的矩形框表示一个时间窗口，一个时间窗口就是一分钟。然后我们将时间窗口进行划分

• 比如图中，我们就将滑动窗口 划成了3格，所以每格代表的是20秒钟。
• 每过20秒钟，我们的时间窗口就会往右滑动一格，每一个格子都有自己独立的计数器
• 比如当一个请求 在0:12秒的时候到达，那么0:00~0:19对应的计数器就会加1。

滑动窗口是怎么解决计数器算法的临界问题的呢？

还是刚才那个例子，0:59到达的100个请求会落在最后的黄色格子中，而1:00到达的请求会落在红色的格子中。当时间到达1:00时，我们的窗口会往右移动一格，那么此时时间周期窗口内的总请求数量一共是200个，超过了限定的一个周期100个，所以触发了限流。

• 计数器算法和滑动窗口算法原理一致，滑动窗口算法就是计数器算法。只是计数器算法没有对时间窗口做进一步地划分，所以只有1格。
• 当滑动窗口的格子划分的越多，那么滑动窗口的滚动就越平滑，限流的统计就会越精确。

漏桶算法

漏桶算法的原理就像它的名字一样, 我们维持一个漏斗， 它有恒定的流出速度,不管水流流入的速度有多快，漏斗出水的速度始终保持不变,类似于消息中间件,不管消息的生产者请求量有多大,消息的处理能力取决于消费者

漏桶的容量=漏桶的流出速度*可接受的等待时长。

• 在这个容量范围内的清求可以排队等待系统的处理，超过这个容量的清求，才会被抛弃。

在漏桶限流算法中，存在下面几种情况:

1. 当清求速度大于漏桶的流出速度时，也就是清求量大于当前服务所能处理的最大极跟值时，触发限流策略.
2. 请求速度小于或等于漏桶的流出速度时，也就是服务的处理能力大于或等于请求量时，正常执行。

漏桶算法有一个缺点:

• 当系统在短时间内有突发的大流量时，漏桶算法处理不了，相当于桶装不了那么大水

令牌桶算法

令牌桶算法，是增加一个大小固定的容著,也就是令牌桶，系统以恒定的速率向令牌桶中放入令牌,如果有客户端来请求，先需要从令牌桶中拿一个令牌，拿到令牌，才有资格访问系统，这时令牌桶中少一个令牌。当令牌桶满的时候，再向令牌桶生成令牌时，令牌会被抛弃。

在令牌桶算法中，存在以下几种情况:

1. 请求速度大于令牌的生成速度：那么令牌桶中的令牌会被取完，后续再进来的清求，由于拿不到令牌，会被限流。
2. 清求速度等于令牌的生成速度：那么此时系统处于平稳状态。
3. 请求速度小于令牌的生成速度:那么此时系统的访问量远远低于系统的并发能力，请求可以被正常处理,令牌桶算法，由于有一个桶的存在，可以处理短时间大流量的场景，这是令牌桶和漏桶的一个区别。