分布式限流方案及实现

优质博文：IT-BLOG-CN

一、限流的作用和意义

限流是对高并发访问进行限制，限速的过程。通过限流来限制资源，可以提高系统的稳定性和可靠性，控制系统的负载，削峰填谷，保证服务质量。

服务限流后的常见处理方式：
【1】拒绝服务；
【2】排队或等待；
【3】服务降级（当服务器压力剧增的情况下，根据当前业务情况及流量对一些非核心服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行）；

二、限流的主要方式

限流可以分为两大类：
【1】单机限流：计数器、互动窗口、漏桶算法、令牌桶算法；

计数器： 取固定大小的时间窗口，并在每个窗口时间内限制请求数量。只需要记录一个计数器，并在每个时间窗口结束时将其重置为零。每当请求进入系统时，我们都会将计数器加一，并检查它是否超过了限制的阈值。这种方式的缺点是：窗口是固定的，在两个窗口边界会有流量超限问题。
在这里插入图片描述

滑动窗口： 滑动窗口的基本思想是在固定窗口基础之上，将一个窗口分为若干个等分的小窗口，每个小窗口对应不同的时间点，拥有独立的计数器。当请求的时间点大于当前窗口的最大时间点时，则将窗口向前平移一个小窗口。如果请求数量超过了小窗口的限制的阈值，则决绝该请求。时间区间精度越高，所需空间容量越大。每一次小窗口就判断是否超过1分钟的阈值，取当前小窗口的前后五分钟的请求量，例如下图虚线框部分。提高了限流的频率和准确性。
在这里插入图片描述

漏桶算法：可粗略的认为就是注水漏水的过程，往桶中以任意流速流入水，以一定速率流出水，当水超过桶容量则触发限流，因为出水速率是不变的，所以保证了资源的请求速率。漏桶算法是一个强制限制请求速率的方式，有两个缺点：
● a)无法应对正常的突发流量：实际上突发一波请求流量是正常现象。漏桶算法中的漏桶容易被突发流量打满，导致后续的正常请求被限流。
● b)无法有效利用资源：严格限制请求量，无法充分利用资源。
在这里插入图片描述

令牌桶算法： 令牌桶算法是对漏桶算法的改进，能在限制调用的平均速率的同时还允许一定程度的突发调用。
限流过程：
● a)系统以恒定的速率产生令牌，然后将令牌放入令牌桶中；
● b)令牌桶有容量限制；
● c)每次请求需要从令牌桶中获取令牌，有令牌则提供法务，无令牌则拒绝服务；
在这里插入图片描述

令牌桶算法一定程度上可以防止突发流量，以每分钟100请求量为例，如果前一分钟使用了90个令牌，则当前就可以使用110个令牌容量，来处理突发请求。作为漏桶算法的改进，令牌桶算法在限流场景下被广泛使用。
Guava为我们提供了很好的基于令牌桶算法的流控工具RateLimiter，可以支持突发流量也可以支持预热等多种功能，简单好用。

【2】分布式限流：Redis令牌桶、发票服务器Sentinel；

三、单机限流 VS 分布式限流

【1】单机限流在单机上运行性能好，状态稳定。但如果分布式系统使用单纯的单机限流，开启HPA后流量会处于半失控状态，如果扩容整个集群限流就会变大，缩容整个集群限流就会变小。
【2】已有的分布式限流方案需要每次/每批请求都需要请求“阈值管理者”单点，增加了服务端的网络开销和不稳定因素，“阈值管理者”的稳定性也是影响结果的一个重要因素。
【3】如果能结合单机限流和分布式限流的优点，就是我们这次需要的分布式限流框架。