赞
踩
几个优化Prompt的点是:
1. 固定窗口限流算法:首先维护一个计数器,将单位时间段当做一个窗口,计数器记录这个窗口接收请求的次数。当次数少于限流阀值,就允许访问,并且计数器+1;当次数大于限流阀值,就拒绝访问;当前的时间窗口过去之后,计数器清零。但有明显的临界问题,如果阈值为5,单位时间窗口为1s,分别在0.8-1s,1-1.2s两个时间段内并发5个请求,理论上是没有超过阈值,但如果按照0.8-1.2s时间段计算,则是并发了10个请求,已经超过阈值。
2. 滑动窗口限流算法:解决了固定窗口限流算法的临界值问题,将单位时间周期分为n个小周期,分别记录每个小周期内接口的访问次数,并根据时间滑动删除过期的小周期。假设单位时间为1s,滑动窗口将其分为5个小周期,则每个小周期0.2s,每过0.2s,滑动窗口向右滑动一格,如果在0.83s时来了一个请求,那么0.8-1s这个小周期的计数器就会加1。
如何解决临近值问题呢?假设单位时间窗口为1s,阈值为5,如果在0.9s时并发了5个请求,落在黄色小周期内,但在过了1s之后,又来了5个请求,就会落在紫色小周期内,但此时窗口已经向又滑动了一格,也就是此时的单位周期为0.2-1.2s,因此紫色小周期内的5个请求会被拒绝。
理论上来说,单位时间内小周期划分的越多,滑动窗口的滚动就会越平滑,对限流的统计就会越精确。该算法虽然解决了临界值问题,但会直接暴力拒绝超额的请求,使得损失部分请求,对产品并不友好。
3. 漏桶算法:该算法处理限流会更加柔性,不存在暴力拒绝。可以理解为注水与漏水的过程,水滴(请求)以某种速率向桶(系统)内流入,桶会以恒定的速率流出水滴(处理请求),桶的容量固定(系统能处理的请求数),如果桶满了,则会溢出水(请求拒绝)。
但该算法不适合面对突发流量请求,因为流出的速率固定,也就系统处理请求的速率不变,面对突发流量肯定希望系统处理的越快越好。
4. 令牌桶算法:该算法可有效应对处理突发流量。有一个令牌管理员,根据限流大小,定速往令牌桶里放令牌。如果令牌数量满了,超过令牌桶容量的限制,那就丢弃。系统在接受到一个用户请求时,都会先去令牌桶要一个令牌。如果拿到令牌,那么就处理这个请求的业务逻辑;如果拿不到令牌,就直接拒绝这个请求。
在本项目中采用了Redisson的RateLimiter,底层为令牌桶限流算法。
内容较多,会持续更新优化。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。