面试官：你知道限流么？

限流在我们日常生活中经常见到，如火车站门口的栏杆、一些景点的门票只出售一定的数量 等等。在我们的开发中也用到了这种思想。也是面试官常问的问题！

面试官：为什么要有限流呢？

在保证系统可用的情况下尽可能多增加进入的人数,其余的人在排队等待,或者返回友好提示,保证系统里面的用户可以正常使用，防止系统雪崩。

面试官：你知道哪些限流算法？

限流算法很多,常见的有三类,分别是 计数器算法、漏桶算法、令牌桶算法 。

（1）计数器：
在一段时间间隔内，处理请求的最大数量固定，超过部分不做处理。
（2）漏桶：
漏桶大小固定，处理速度固定，但请求进入速度不固定（在突发情况请求过多时，会丢弃过多的请求）。
（3）令牌桶：
桶的大小固定，令牌的产生速度固定，但是消耗令牌（即请求）速度不固定（可以应对一些某些时间请求过多的情况）；每个请求都会从令牌桶中取出令牌，如果没有令牌则丢弃该次请求。

面试官：能不能详细介绍一下？

计数器限流

在一段时间间隔内，处理请求的最大数量固定，超过部分不做处理。

举个🌰,比如我们规定对于A接口，我们1分钟的访问次数不能超过100次。

那么我们可以这么做：
在一开始的时候，我们可以设置一个计数器counter，每当一个请求过来的时候，counter就加1，如果counter的值大于100并且该请求与第一个请求的间隔时间还在1分钟之内，那么说明请求数过多,拒绝访问；

如果该请求与第一个请求的间隔时间大于1分钟，且counter的值还在限流范围内，那么就重置 counter,就是这么简单粗暴。
图片说明

计数器限流的不足：
这个算法虽然简单，但是存在临界问题，如下图：

从上图中我们可以看到，假设有一个恶意用户，他在0:59时，瞬间发送了100个请求，并且1:00又瞬间发送了100个请求，那么其实这个用户在 1秒里面，瞬间发送了200个请求。

我们刚才规定的是1分钟最多100个请求（规划的吞吐量），也就是每秒钟最多1.7个请求，用户通过在时间窗口的重置节点处突发请求，可以瞬间超过我们的速率限制。

恶意用户有可能通过算法的这个漏洞，瞬间压垮我们的应用。

漏桶限流

漏桶算法限流的基本原理为：水（对应请求）从进水口进入到漏桶里，漏桶以一定的速度出水（请求放行），当水流入速度过大，桶内的总水量大于桶容量会直接溢出，请求被拒绝。
大致的漏桶限流规则如下：
（1）进水口（对应客户端请求）以任意速率流入进入漏桶。
（2）漏桶的容量是固定的，出水（放行）速率也是固定的。
（3）漏桶容量是不变的，如果处理速度太慢，桶内水量会超出了桶的容量，则后面流入的水滴会溢出，表示请求拒绝。
图片说明

漏桶算法其实很简单，可以粗略的认为就是注水漏水过程，往桶中以任意速率流入水，以一定速率流出水，当水超过桶容量（capacity）则丢弃，因为桶容量是不变的，保证了整体的速率。

以一定速率流出水，
图片说明
削峰：有大量流量进入时,会发生溢出,从而限流保护服务可用
缓冲：不至于直接请求到服务器, 缓冲压力
漏桶的不足：
漏桶的出水速度固定，也就是请求放行速度是固定的。
漏桶出口的速度固定，不能灵活的应对后端能力提升。比如，通过动态扩容，后端流量从1000QPS提升到1WQPS，漏桶没有办法。