在一个分布式的高可用系统中,限流是必备的操作。这个流可以是:网络流量,带宽,每秒处理的事务数,每秒请求数,并发请求数,或者业务上的指标等。
找了很多资料,写的最详细的是王争老师的一篇文章 微服务接口限流的设计与思考 。所以决定给公司的API优化下,加入接口的限流!因为公司的项目都是Laravel写的,所以把限流的操作都放到了中间件中,这样可以统一配置。
下面的实现都是通过使用Redis来写的Laravel中间件。
创建一个中间件的话可以自己手动创建,也可以通过命令 php artisan make:middleware xxx
。如果想要全部路由都可以使用 加入到 app/Http/Kernel.php
的 $middleware
数组中即可。 如果想要自己指定部分路由使用中间件就加入到 $routeMiddleware
数组中,然后显示指定路由调用。
另外我还简单写了个模拟的配置文件如下 config/grant.php
:
|
|
固定时间窗口限流
这种也叫计数器法限流,是限流算法里最简单也是最容易实现的一种算法。主要通过来一个记一个,然后判断在有限时间窗口内的数量是否超过限制即可。
比如限制每秒100次请求,多余的请求就拒绝或者阻塞排队。
但是这会出现一个问题,比如第一秒的最后10ms,和第二秒的前10ms内有大量的请求同时到来,根据计算他们是合法的其结果是 >100
所以有可能压垮系统。
php实现伪代码: GrantMiddleware.php
|
|
滑动时间窗口限流
滑动时间窗口限流是固定时间窗口的优化版,可以解决它的2个时间交汇点并发过高问题。
对比固定时间窗口限流算法,滑动时间窗口限流算法的时间窗口是持续滑动的,并且除了需要一个计数器来记录时间窗口内接口请求次数之外,还需要记录在时间窗口内每个接口请求到达的时间点,对内存的占用会比较多。
实现步骤:
滑动窗口记录的时间点 list = (t_1, t_2, …t_k),时间窗口大小为 1 秒,起点是 list 中最小的时间点。当 t_m 时刻新的请求到来时,我们通过以下步骤来更新滑动时间窗口并判断是否限流熔断:
Step1: 检查接口请求的时间 t_m 是否在当前的时间窗口 [t_start, t_start+1 秒) 内。如果是,则跳转到 STEP 3,否则跳转到 STEP 2.
Step2: 向后滑动时间窗口,将时间窗口的起点 t_start 更新为 list 中的第二小时间点,并将最小的时间点从 list 中删除。然后,跳转到 STEP 1。
Step3: 判断当前时间窗口内的接口请求数是否小于最大允许的接口请求限流值,即判断: list.size < max_hits_limit,如果小于,则说明没有超过限流值,允许接口请求,并将此接口请求的访问时间放入到时间窗口内,否则直接执行限流熔断。
即便滑动时间窗口限流算法可以保证任意时间窗口内接口请求次数都不会超过最大限流值,但是仍然不能防止在细时间粒度上面访问过于集中的问题,基于时间窗口的限流算法,不管是固定时间窗口还是滑动时间窗口,只能在选定的时间粒度上限流,对选定时间粒度内的更加细粒度的访问频率不做限制。比如最后1ns内200次请求系统还是要挂!
php实现伪代码如下:
|
|
令牌桶限流
令牌桶:
- 接口限制 t 秒内最大访问次数为 n,则每隔 t/n 秒会放一个 token 到桶中;
- 桶中最多可以存放 b 个 token,如果 token 到达时令牌桶已经满了,那么这个 token 会被丢弃;
- 接口请求会先从令牌桶中取 token,拿到 token 则处理接口请求,拿不到 token 则执行限流。
令牌桶算法看似比较复杂,每间隔固定时间都要放 token 到桶中,但并不需要专门起一个线程来做这件事情。每次在取 token 之前,根据上次放入 token 的时间戳和现在的时间戳,计算出这段时间需要放多少 token 进去,一次性放进去,所以在实现上面也并没有太大难度。这种的话是王争老师说的,不过我稍微改了下,改成了使用计数器的记录时间然后配合redis的队列。
php实现伪代码:
|
|
漏桶限流
漏桶算法大致如下:
漏桶算法稍微不同与令牌桶算法的一点是:对于取令牌的频率也有限制,要按照 t/n 固定的速度来取令牌,所以可以看出漏桶算法对流量的整形效果更加好,流量更加平滑,任何突发流量都会被限流。因为令牌桶大小为 b,所以是可以应对突发流量的。这个我就没有去实现了!有时间在补
总结
对于令牌桶的算法虽然可以很好的限制流量,但是它是否决式的,会导致误杀很多正常的请求。所以令牌桶和漏桶算法比较适合阻塞式限流,比如一些后台 job 类的限流,超过了最大访问频率之后,请求并不会被拒绝,而是会被阻塞到有令牌后再继续执行。对于像微服务接口这种对响应时间比较敏感的限流场景,会比较适合选择基于时间窗口的否决式限流算法,其中滑动时间窗口限流算法空间复杂度较高,内存占用会比较多,所以对比来看,尽管固定时间窗口算法处理临界突发流量的能力较差,但实现简单,而简单带来了好的性能和不容易出错,所以固定时间窗口算法也不失是一个好的微服务接口限流算法。