基于系统负载的动态限流组件 dynamic-limiter
背景
一个系统的处理能力是有限的,当请求量超过处理能力时,通常会引起排队,造成响应时间迅速提升。如果对服务占用的资源量没有约束,还可能因为系统资源占用过多而宕机。因此,为了保证系统在遭遇突发流量时,能够正常运行,需要为你的服务加上限流。
通常限流可以分为两类:单机限流、全局限流。常见的单机限流工具有 Guava RateLimiter 和 Java Semaphore,全局限流可以用 Redis 做全局计数器来实现,基础架构组也提供了一个灵活的全局限流组件 common-blocking。这些限流工具有一个共同的缺点:都需要手动设置一个固定的限流阈值。
首先,手动设置固定阈值需要做容量评估,准确的容量评估是比较难的。其次,在每次系统更新升级后,阈值会变得不再准确,需要重新调整,比较繁琐。再次,固定阈值也不能应对服务器性能波动的情况,对于一些日志量比较大的应用,整点日志压缩时,会消耗较多性能,此时系统的处理能力肯定比其他时候要稍差一些。最后,应用大多运行在虚拟机上,同一个实体机上的虚拟机之间也会相互影响,这个体现在监控上就是 CPU 使用率里的 steal 值了。
既然固定阈值有这么多缺点,我们就想有没有什么办法能够自动计算限流阈值呢?下面介绍一下:基于系统负载的动态限流。
动态限流原理
为什么叫动态限流呢?因为我们希望在系统运行时,限流阈值能够根据实际情况做动态调整。具体根据什么来调整呢?系统负载,这里我们使用了最常见的三种监控指标:CPU 使用率、Load 和服务的响应时间。
动态限流的目标是,计算一个合理的阈值,让系统在提供最大处理能力的同时,保持健壮,不被压垮。
动态限流的基本思路可以看下面这幅图,系统负载反过来说就是系统的健康程度。当系统负载较低,处于健康状态时不限流。当系统负载稍高,处于不健康状态时,以最近几秒处理请求的 QPS 计算限流阈值。当系统负载过高,状态恶化时,让限流阈