高并发流量控制与算法实现思路

前言

昨天看了一篇关于高并发流量控制的文章，感觉对我启发非常的大，所以写一篇记录总结一下，方便于以后我自己的学习与复盘。

简介

首先要知道什么是大流量

听到大流量，我们首先可能会冒出：TPS（每秒事物量），QPS（每秒请求量），其实并没有一个绝对的数字，如果这一个流量对系统造成了压力，影响了系统的正常运行与性能，那么这个量就可以称之为大流量了。
应对大流量的一些手段
- 缓存：说白一点，就是让数据尽早的进入缓存，离缓存近一点，不要大量的频繁访问数据库。
- 降级：如果不是核心的链路，那么就把这个服务降级，打个比喻，现在的网站或者app都是动态页面，千人千面，每个人看到的也许都不一样，例如商城的商品推荐等等，所以在大流量的冲击下，可以把这个服务降级，从而提高核心服务的响应速度
- 限流：如果服务器在一段时间内承受的流量超过了服务器的承受能力，可能会造成系统的崩塌，所以我们可以在一个时间段内规定访问请求的数量，将流量控制在一个服务器能接受的范围内，同时尽可能的提升系统的吞吐量
注意到，有些时候，缓存的降级是解决不了问题的，就比如说，电商的双十一，用户的购买行为等，都是设计到大量的数据库写入操作，而且都是核心链路，没有办法降级，这个时候限流就显得非常的重要

限流的方法

计数器

计数器是一种比较简单的限流算法，用于非常的广泛，在接口层面，很多地方使用这种方式限流，思路就是：在一段时间里面，进行技术，与阀值进行一个比较，到了时间的临界点九江计数器清零

代码实现

缺点：这里需要注意的是，存在一个时间临界点的问题。举个栗子，在12:01:00到12:01:58这段时间内没有用户请求，然后在12:01:59这一瞬时发出100个请求，OK，然后在12:02:00这一瞬时又发出了100个请求。这里你应该能感受到，在这个临界点可能会承受恶意用户的大量请求，甚至超出系统预期的承受。

滑动窗口

由于计数器存在一个临界点的缺陷，所以后面出现了一个滑动窗口算法来解决。

缺点：滑动窗口的意思是说把固定时间片，进行划分，并且随着时间的流逝，进行移动，这样就巧妙的避开了计数器的临界点问题。也就是说这些固定数量的可以移动的格子，将会进行计数判断阀值，因此格子的数量影响着滑动窗口算法的精度。

漏桶

滑动窗口算法有效的避免了时间临界点的问题，但是还是存在时间片的概念，而漏桶算法在这方面比滑动窗口更加的高级先进。

算法思路：存在一个固定的桶，进水的速率不确定，但是出水的速率是恒定的，当水满的时候就会溢出

代码实现：

缺点：漏桶的出水速度是恒定的，那么就是说如果瞬时大流量的话，会有很大一部分请求被丢失掉（就是所谓的溢出）

令牌桶

为了解决漏桶算法的缺陷，出现了一个令牌桶的概念，本质是在漏桶算法上的改良

生成令牌的速度是恒定的，而请求去拿令牌是没有速度限制的。这意味，面对瞬时大流量，该算法可以在短时间内请求拿到大量令牌，而且拿令牌的过程并不是消耗很大的事情。（有一点生产令牌，消费令牌的意味）

不论是对于令牌桶拿不到令牌被拒绝，还是漏桶的水满了溢出，都是为了保证大部分流量的正常使用，而牺牲掉了少部分流量，这是合理的，如果因为极少部分流量需要保证的话，那么就可能导致系统达到极限而挂掉，得不偿失。

代码实现:

结尾

上面所说的限流的一些方式，都是针对单机而言的，其实大部分的场景，单机的限流已经足够了。

ps：本文非原创，原文出自与微信公众号：java面试那些事儿