系统如何做限流处理(限流功能怎么实现)

导语：系统如何做限流

上篇文章说到要在缓存层之上加个限流，减少流量流入数据库，限制到系统能承受的TPS值（每秒处理的消息数），限流分为技术层面限流和业务层面限流，技术层面的限流可以是限制并发数、资源数、请求数，而业务层面的限流则是针对某些业务场景做的限流，比如黑白名单。

技术层面的限流：Nginx的limit_conn模块限制瞬时并发连接数、Tomcat/Mysql配置最大连接数、最大处理线程数。对于稀缺资源（比如数据库、线程），需要加以限制，因为多个系统都在使用，有时可能是一台数据库服务器要服务多台应用服务器，又或者是在计算密集型的应用中，线程资源数的分配等于CPU核数，所以要用池化技术来限制总资源数。假设分配给每个应用的数据库连接是100，那么最多可以使用100个资源，超出可以等待或抛出异常。

如果只想限制某个接口的请求数，有三种限流方式：

（1）限制接口总并发数

（2）限制某个时间段内的请求数

（3）用令牌桶、漏桶算法，平滑地限流接口请求数

限制接口总并发数，可以用一个静态全局并且原子类型的计数变量，统计每个请求数。超出限流数，提示用户或者对服务降级，下面使用Java中的原子数据类型AtomicLong做限流

限制接口总并发数

限制某个时间段内的请求数，如每秒/每分钟/每天的请求数的请求量，同样用计数法来判断，不过是设置一个有效期的本地缓存来计数。下面使用Guava的Cache来存储计数器

限制某个时间段内的请求数

上述方法假如要统计一分钟内的请求量，要把一分钟转化成60秒（60个key）分别计数，然后求总和来判断限流数。以此类推，如果时间窗口大，这种办法是很耗内存的，所以本地缓存计数不可取。改进办法是用Redis的incr命令计数做统一限流，先通过key是否存在有效期，不存在：计数加1，设置缓存过期时间，否则计数加1，往下执行。

Redis统一限流

假设应用服务器部署了多份，本地限流就变成了分布式限流，需要事先计算好每台机器的限流数。分布式限流相比统一限流的好处是，如果其中一台服务器宕机，限流仍然能正常工作；但用Redis做统一限流，如果宕机，限流就失效。坏处是限流数不好平均判断，有可能负载均衡请求到一台已达到限流阈值的机器，这样会误判并损失部分请求。上面介绍的限流方法都比较简单粗暴，超过限流数时流量马上被切断，但实际应用不需要流量被瞬间切断。好比地铁上的限流，不是说某个时间段内超过乘载人数，就不允许进站了，而是希望减缓人们进站的速度，从而缓冲每个人进站时间，这样每趟地铁能够限流服务人数。对于系统也是如此，不希望损失部分请求，产品体验上不友好。

下篇将继续讲讲用令牌桶、漏桶算法做限流，既能解决流量被瞬间切断的问题，又能平滑地限流接口请求数。平滑的意思是来多少流量都接收，但流入的流量被限制了流入速率。

本文内容由小莉整理编辑！