上篇文章《为什么大公司都要做流量治理?》跟大家聊了下做流量治理的真正目的是什么。如果你要开发一个流量治理的平台或者一个限流的框架,那么必不可少的就是要选择一种合适的限流算法。本篇文章就跟大家聊聊目前常用的限流算法有哪些。
计数器
计数器是最简单,最直接明了的限流算法。说白了就是进行数字累加操作,也就是count++ 这你总能看懂吧!
单机限流可以直接使用LongAdder或者AtomicLong这些原子类进行计数操作即可。用Semaphore也可以,Semaphore内部本身就是计数器的方式实现。
集群限流可以使用Redis的incr进行计数累加即可,用其他的存储也可以,核心就是要有集中存储计数的地方。
计数器算法也分为两种形式,一种是有时间段的限制,另一种是没有时间段的限制。
有时间段限制
有时间段限制就是你限流的时长是多少,一般我们都会以秒为单位。比如限制QPS为1000。
有时间限制会存在一个临界区的问题,假设第1秒中的第999毫秒的时候,来了800个请求,这个时候是没有超过1000 QPS的限制。然后第2秒的1毫秒来了800个请求,相隔几毫秒,很有可能前面的请求还没执行完成,这么又来了,其实这个时候的请求已经超出了你系统能够承受的范围了,也就失去了限流的效果。
如果非得要用有时间限制的计数器算法,那么可以将时间单位调的越小越好。当然还有其他的算法能够解决这个临界区的问题,下面会介绍到。
无时间段限制
无时间段限制就不会存在临界区的问题,请求进来数量加一,请求结束数量减一。将并发量最高永远限制在你想要的范围内。跟Semaphore是一样的作用。
这个其实跟我们去饭店吃饭一样,饭店总共10个座位,坐满了你就得在外面等着叫号。如果有客人吃完离开了,空了一个座位出来,下一个客人才能进去。这样就能永远保证进去的人不超过饭店的座位数量,也在厨师和服务员能够服务的范围之内。
伪代码示列:
@Slf4j
public class RatelimitFilter implements Filter {
private AtomicLong atomicLong = new AtomicLong();
@Override
public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
HttpServletRequest request = (HttpServletRequest)servletRequest;
try {
long currentQps = atomicLong.incrementAndGet();
log.info("当前QPS: {}", currentQps);
if (currentQps > 1) {
throw new RuntimeException("限流中。。。。");
}
try {
// 模拟业务耗时
TimeUnit.SECONDS.sleep(2);
} catch (InterruptedException e) {
e.printStackTrace();
}
} finally {
atomicLong.decrementAndGet();
}
}
}
滑动窗口
了解滑动窗口前先需要了解下固定窗口,固定窗口比较简单,也就相当于固定大小。比如限制1秒内的访问次数,那么这个1秒就是一个固定的时间窗口。
滑动窗口可以将固定窗口再进行细分成多个窗口,比如将1秒中的固定窗口细分成5个窗口,那么每个窗口的时间就是200毫秒。
假设每秒钟限流100,在201ms-1000ms之间的时候来了99个请求,不满足限流条件,放行。在第2秒的100ms的时候来了999个请求,这个时候多余的请求会被限制。当前窗口的范围是1秒的201ms~2秒的200ms。
通过滑动窗口算法,同时也能解决了上面计数算法临界区的问题。窗口是一直滑动的,计算的数量也不是固定时间内的,而是随着窗口的滑动一直在变化。
漏桶
漏桶算法能够很好的保证稳定性,可以将突发的高流量以固定的速度流出来保证稳定性。
我记得小时候,家里每年都会酿米酒,甜甜的米酒很好喝。当然我们不是来讲米酒好不好喝的问题,而是要讲解漏洞算法。那么漏桶算法跟米有又有什么联系呢?
酿好的米酒会装在酒坛里面,有时候村里的其他人需要用到米酒的时候,如果自己家里没有酿的话就会去别人家买,一般都是拿一个瓶子来装,比如我们的可乐瓶子。
但是可乐瓶子的入口很小,直接往里面倒酒的话很容易洒出来。这个时候就有一个装酒的漏斗,这个东西就跟我们今天要讲的漏桶一样,下面很小,上面很大。酒就相当于流量,倒入这个漏桶里面,然后会从下面很小的口流出来,这个速度是固定的,这么说相信大家一定明白了什么是漏桶算法吧。
漏桶算法的优点是能够以固定的速率去控制流量,稳定性比较好。缺点就是无法应对突发流量的来袭,我们来分析具体的分析下这个缺点。
假设你的漏桶出口固定了每秒钟只能通过100个请求,如果此时有150个请求,无论你后方的系统能不能抗住这150个请求,通过漏桶算法都会将另外50个请求进行拦截,只能等前面的100个请求结束后才能继续放行剩下的50个请求。
那么有没有什么算法既能做流量控制,又能应对突发流量的场景呢?接下来为你介绍令牌桶算法。
令牌桶
令牌桶算法用比较官方的术语来解释就是:一个有固定容量的桶,按一定的速度往桶里面放令牌,如果桶里面装不下令牌了就不放了。有请求进来就去桶里面获取对应的令牌,能拿到令牌就可以通过,拿不到就拒绝,也就是限流了。
我们还是用生活中的方式来解释下令牌桶的原理,有天你带着你的女朋友去吃自助餐,那些吃的你们可以随便拿,如果拿完了,是不是就得等待餐厅重新供应了才行,这就是限流了。同时,餐厅会定时的供应新的食物,食物供应上了,你能够拿到了那就是放行,相当于拿到了令牌。
有令牌如下图所示:
无令牌如下图所示:
总结
本文对目前主流的限流算法进行了讲解,相信大家有了一个初步的认识。这些算法在面试中也经常被问到,同时我也是通过各种生活中的案例来举例,希望大家能够彻底的理解这些算法的原理。
大家好,我是从古代穿越过来的美男子:架构摆渡人。我将把我的武功秘籍全部传授与你们,觉得有用请分享给身边的朋友。来个三连吧,感谢各位!