分布式场景常用限流算法

为什么需要限流？

在高并发场景下，你的系统不足以支撑高频次访问，如果不加以限制，会造成整个系统不可用。作为一种保护系统的兜底机制。比如系统仅支持5000QPS（每秒钟访问5000次），超过了这个次数，系统无法处理，剩下的请求就需要排队，然后排队的请求还没处理，新来的请求继续排队，排着排着资源就会耗尽，造成宕机。

常见限流算法

常见的限流算法由如下四种

• 计数器限流算法
• 滑动窗口限流算法
• 令牌桶限流算法
• 漏桶限流算法

1. 计数器限流算法

在有效时间内计算请求次数，调用一次+1，调用结束-1，可以使用redis的incr或其他计数工具实现。

优点：

实现简单

缺点：

第一个时间段的结尾和第二个时间段的开头组成的新时间段容易超过阈值。例如：5秒内请求不能超过10次，第一个5秒是0-5，第二个是5-10，那你在4.9秒、5.1秒时分别请求10次，但其实4.9和5.1之间不过0.2秒而已，但却请求了20次，会超过10次的阈值。

适用场景：

短信验证码，间隔固定时间可重复发送

2. 滑动窗口限流算法

其实也是一种计数器限流算法，只不过每过一个步长，整体时间区域滑动一下，以滑动窗口的机制减少临界值带来的超过阈值的问题。

优点：

有效降低了临界值带来的超过阈值的问题

缺点：

计数器的问题没有从根本上得到解决，只是范围缩小了。例如：还是5秒内请求不能超过10次，滑动窗口步长为1秒，那么在初始是0-5秒，第一次滑动是1-6秒。在滑动前的0.9秒和滑动后的5.1秒分别请求10次，在0.9和5.1之间不到5秒，请求了20次，又超过了10次的阈值。

第三方实现：

Spring的熔断（Hystrix）

3. 令牌桶限流算法

有一个令牌桶和定时器，在一个时间段内往令牌桶里生成固定数量的令牌，你请求就从桶里拿一个令牌，如果令牌没了，就排队或拒绝服务。

优点：

解决了计数器限流算法的临界值超过阈值的问题。并且可以支持突发的流程，把令牌一下子全部拿走。

缺点：

不能保持匀速请求的处理

适用场景：

突峰流量、瞬时流量

第三方实现：

Google的Guava，Redisson限流

4. 漏桶限流算法

恒定速率的限流算法，不论客户端请求量是多少，服务端处理请求的速度都是恒定的。请求过来，先放到一个队列里，然后服务端以一定的频率去漏桶处理请求。若漏桶队列满了，则请求排队或拒绝服务。

优点：

可以实现请求处理速度的恒定

缺点：

对突峰、瞬时流量处理速度过慢

适用场景：

基于MQ实现的生产者消费者模型