高并发流量控制与算法实现思路
前言
昨天看了一篇关于高并发流量控制的文章,感觉对我启发非常的大,所以写一篇记录总结一下,方便于以后我自己的学习与复盘。
简介
-
首先要知道什么是大流量
听到大流量,我们首先可能会冒出:TPS(每秒事物量),QPS(每秒请求量),其实并没有一个绝对的数字,如果这一个流量对系统造成了压力,影响了系统的正常运行与性能,那么这个量就可以称之为大流量了。
-
应对大流量的一些手段
- 缓存 :说白一点,就是让数据尽早的进入缓存,离缓存近一点,不要大量的频繁访问数据库。
- 降级 :如果不是核心的链路,那么就把这个服务降级,打个比喻,现在的网站或者app都是动态页面,千人千面,每个人看到的也许都不一样,例如商城的商品推荐等等,所以在大流量的冲击下,可以把这个服务降级,从而提高核心服务的响应速度
- 限流 :如果服务器在一段时间内承受的流量超过了服务器的承受能力,可能会造成系统的崩塌,所以我们可以在一个时间段内规定访问请求的数量,将流量控制在一个服务器能接受的范围内,同时尽可能的提升系统的吞吐量
注意到,有些时候,缓存的降级是解决不了问题的,就比如说,电商的双十一,用户的购买行为等,都是设计到大量的数据库写入操作,而且都是核心链路,没有办法降级,这个时候限流就显得非常的重要
限流的方法
-
计数器
计数器是一种比较简单的限流算法,用于非常的广泛,在接口层面,很多地方使用这种方式限流,思路就是:在一段时间里面,进行技术,与阀值进行一个比较,到了时间的临界点九江计数器清零
代码实现
缺点: 这里需要注意的是,存在一个时间临界点的问题。举个栗子,在12:01:00到12:01:58这段时间内没有用户请求,然后在12:01:59这一瞬时发出100个请求,OK,然后在12:02:00这一瞬时又发出了100个请求。这里你应该能感受到,在这个临界点可能会承受恶意用户的大量请求,甚至超出系统预期的承受。
-
滑动窗口
由于计数器存在一个临界点的缺陷,所以后面出现了一个滑动窗口算法来解决。
缺点:滑动窗口的意思是说把固定时间片,进行划分,并且随着时间的流逝,进行移动,这样就巧妙的避开了计数器的临界点问题。也就是说这些固定数量的可以移动的格子,将会进行计数判断阀值,因此格子的数量影响着滑动窗口算法的精度。
-
漏桶
滑动窗口算法有效的避免了时间临界点的问题,但是还是存在时间片的概念,而漏桶算法在这方面比滑动窗口更加的高级先进。
算法思路:存在一个固定的桶,进水的速率不确定,但是出水的速率是恒定的,当水满的时候就会溢出
代码实现:
缺点:漏桶的出水速度是恒定的,那么就是说如果瞬时大流量的话,会有很大一部分请求被丢失掉(就是所谓的溢出)
-
令牌桶
为了解决漏桶算法的缺陷,出现了一个令牌桶的概念,本质是在漏桶算法上的改良
生成令牌的速度是恒定的,而请求去拿令牌是没有速度限制的。这意味,面对瞬时大流量,该算法可以在短时间内请求拿到大量令牌,而且拿令牌的过程并不是消耗很大的事情。(有一点生产令牌,消费令牌的意味)
不论是对于令牌桶拿不到令牌被拒绝,还是漏桶的水满了溢出,都是为了保证大部分流量的正常使用,而牺牲掉了少部分流量,这是合理的,如果因为极少部分流量需要保证的话,那么就可能导致系统达到极限而挂掉,得不偿失。
代码实现:
结尾
上面所说的限流的一些方式,都是针对单机而言的,其实大部分的场景,单机的限流已经足够了。
ps:本文非原创,原文出自与微信公众号:java面试那些事儿