1 何谓限流
限流，顾名思义，便是限制流量的意思。系统规定在一段时间内只能进入这么多的流量，如果超过限额的话，那就不好意思了，我这个系统接受不了。通过限流算法，我们可以控制系统的 qps，更好地对系统提供保护。
本文致力于介绍几种我们常用的限流算法，同时会对其原理进行一定程度的剖析，希望大家能有所收获。
2 计数器算法
算法原理
计数器算法是最简单的限流算法，假设我们规定 A 接口在1小时之内的访问次数不能超过1000次，我们可以在开始时设置一个计数器，只有有一个请求进来，计数器的值就加一。如果计数器的值大于1000，而且该次请求与第一次请求的间隔时间小于1小时，说明请求过多，需要执行拒绝策略；如果该次请求与第一次请求的间隔时间大于1小时，直接重置计数器即可。
存在的问题
该算法虽然比较简单，但是存在一个临界问题。
假设存在一个恶意用户，在第一个小时的最后一秒发送了1000个请求，又在第二个小时的第一秒再次发送了1000个请求，通过在时间窗口的重置节点处突发请求，瞬间超过我们的速率限制。恶意用户可能通过这个算法的漏洞，在一个较短的时间内制造大量的流量，来压垮我们的应用。
实现方法
使用 redis 的 incr 原子自增性。
3 滑动窗口算法
算法原理
计数器算法由于其存在的临界问题，统计的精度过低，可能在时间窗口的重置节点处接收大量流量，为解决这个问题，我们引入了滑动窗口算法。
我们依然使用上面的例子，把一个时间窗口设置为1小时，然后我们再对时间窗口进行划分。例如，我们把时间窗口划分为60格，即每一分钟代表一格，每过一分钟，时间窗口都会往右滑动一格，每一格都有自己的计数器。
对临界问题的解决
我们上面探讨过这个一个情节，一个恶意用户在第一个小时的最后一秒发送了1000个请求，又在第二个小时的第一秒再次发送了1000个请求。在滑动窗口算法中，最后一秒到达的1000个请求会在一个格子中，第一秒到达的1000的请求会在一个格子中，当新的一分钟到来时，时间窗口会向右移动一格，时间窗口的总请求数量一定超标（因为时间窗口包括了最近的这两个格子，这时至少有2000个请求），所以触发限流操作。
计数器算法其实就是只有一格的滑动窗口算法，当滑动窗口算法的格子划分越多，限流的统计就越精确。
4 令牌桶算法
请求在被处理之前，需要首先获取一个令牌，才能执行接下来的业务逻辑，处理完业务逻辑需要将令牌删除。令牌桶是一个存放令牌的地方，它会根据限流大小，会按照一定的速率向桶中添加令牌。
令牌桶会设置最大的放置令牌限制，当令牌桶满了，新添加的令牌会被直接丢弃；令牌桶也有最低限额，当令牌数到达最低限额时，请求处理完之后将不会删除令牌。
5 漏桶算法
所谓漏桶，顾名思义，便是一个漏水的桶，我们往这个桶加水的速率可能是任意的，但桶漏水的速度是必然恒定的。如果流入水的速率过快，已经超过桶的容量大小，那水便会直接流出（被丢弃）。漏桶算法便是在此基础上设计的。
所谓漏桶算法，便是当访问请求到达时，直接放置进入漏桶，如漏桶当前容量已到达限流上限，则触发限流策略。漏桶会以固定的速率释放访问请求，直到漏桶为空。
6 聊聊令牌桶算法与漏桶算法的区别
漏桶算法可以限制数据的平均传输速率，而令牌桶算法除了能够限制数据的平均传输速率外，还能够允许某种程度的突发传输。因为在令牌桶算法中，只要令牌桶中存在令牌，那么就允许突发地传输数据直到达到用户配置的门限，所以它适合于具有突发特性的流量。
参考：三种常见的限流算法
