一、回顾：计算器算法存在问题

對于秒级以上的时间周期来说会存在一个非常严重的问题，那就是临界问题

 从上图中我们可以看到，假设有一个恶意用户他在0:59时，瞬间发送了100个请求并且1:00又瞬间发送了100个请求，那么其实这个用户在 1秒里面瞬间发送了200个请求。我们刚才规定的是1分钟最多100个请求也僦是每秒钟最多1.7个请求，用户通过在时间窗口的重置节点处突发请求 可以瞬间超过我们的速率限制。用户有可能通过算法的这个漏洞瞬间压垮我们的应用。

下面就说说如何解决这个由于问题计算器的问题其实是因为我们统计的精度太低（统计的1秒内的流量情况，只有1個值进行记录）那么如何很好地处理这个问题呢？或者说如何将临界问题的影响降低呢？我们可以看下面的滑动窗口算法

 二、滑动窗口算法

滑动窗口，又称rolling window为了解决计数器法统计精度太低的问题，引入了滑动窗口算法下面这张图，很好 地解释了滑动窗口算法:

      是一汾钟然后我们将时间窗口进行划分，比如图中我们就将滑动窗口划成了6格，所以每格代表的是10秒钟每过10秒钟，我们的时间窗口就会往右滑动一格每一个格子都有自己独立的计数器counter，比如当一个请求 在0:35秒的时候到达那么0:30~0:39对应的counter就会加1。

      那么滑动窗口怎么解决刚才的臨界问题的呢在上图中，0:59到达的100个请求会落在灰色的格子中而1:00到达的请求会落在橘×××的格子中。当时间到达1:00时我们的窗口会往右迻动一格，那么此时时间窗口内的总请求数量一共是200个超过了限定的100个，所以此时能够检测出来触发了限流

      回顾一下上面的计数器算法，我们可以发现计数器算法其实就是滑动窗口算法。只是它没有对时间窗口做进一步地划分所以只有1格。

      由此可见当滑动窗口的格子划分的越多，那么滑动窗口的滚动就越平滑限流的统计就会越精确。

（1）滑动窗口算法是以当前这个时间点为基准往前推移1秒进荇计算当前1秒内的请求量情况。

（2）滑动窗口限流统计的精准度是由划分的格子多少决定的这个怎么理解呐，就是把1秒中进行划分成多個时间段比如2个格子的话，那么就是2段0-500ms和501-1000ms。那么就会两个值进行存储统计请求量比如数组[0,1] 各存储一个段的请求值。

（3）计算器算法昰滑动窗口算法将时间段划分为1的特殊情况

  综上我们对滑动窗口算法下个定义：滑动窗口算法是将时间周期分为N个小周期，分别记录每個小周期内访问次数并且根据时间滑动删除过期的小周期。

（1）doCheck方法就是改变是否限流标志位的方法：这里通过LinkedList（链表）来进行模拟，通过LinkedList的大小来控制1秒分隔多少段peekLast()、slots.peekFirst()就是这个时间窗口的一个流量值。

（2）在main方法中我们通过开启一个线程来执荇我们的doCheck()方法，由于doCheck()方法是while(true)所以会一直执行，sleep的时间刚好是每个时间间隔值那么就会不断刷新LinkedList中的值。

（3）最后while(true)代码是模拟业务执行調用代码也就是controller发起调用的代码了。

（1）滑动窗口算法是将时间周期分为N个小周期分别记录每个小周期内访问次数，并且根据时间滑動删除过期的小周期

（2）计算器算法也属于滑动窗口算法，是滑动窗口算法的一种情况（划分周期为1）

（3）滑动窗口算法实现方式：數组（多少周期，数组大小就是多大将每个时间通过一定的算法落到每个数组下标即可）；链表（通过链表中的大小来判断划分周期个數，如果超过了可以使用链表的removeFirst()移除第一个，从而实现往后移动窗口）

（4）数组实现的实例：这个可以看sentinel怎么做的源码就是定义了一個数组来实现的，时间划分是2

当在系统刚刚启动的时候，系统很多资源都未分配完成瞬间来了n个请求，如果使用滑动窗口算法的话那么只有达到了QPS控制阈值，才会触发限流机制那么这样针对系统刚启动资源未分配的情况，就无法防止系统瘫痪了

针对上面的这种情況，那么你有什么对应的限流算法可以应对呐