spring-cloud-sentinel ---流控算法---review
创始人
2025-05-30 09:28:43
0次
计数器算法
- 计数器算法,限定每个固定时间能处理的请求总数,例如1分钟100,如果在第一个一分钟,总共请求60次,接着第二个一分钟,counter又会从0 开始技术,如果在1.5分钟的时候,达到了100个,那么后面半分钟的请求将会被拒绝。
- 这种固定时间窗口的限流算法可以用在短信发送频次限制上,例如,一个用户一分钟只能收到n次短信

- 计数器算法存在的问题,如果在第一分钟的0:58 ~ 第二分钟的1:02 这个时间段内,分别出现了100 次请求,安计数器逻辑里说是都能通过的,但是这一分钟内的总请求量是超过了100 的。

滑动窗口
- 滑动窗口算法是一种流量控制技术,在TCP网络通信协议中,采用了 滑动窗口解决网络拥塞的情况。
- 做法是,在固定窗口中分割出多个小窗口,分别在每一个小时间窗口中记录访问次数,然后根据时间将窗口向前滑动,并且删除过期的小时间窗口。最终我们自需要统计滑动窗口范围内的所有小的时间窗口计数即可。
- 如下图,将一个时间窗口分为4个小的窗口,每个小时间窗口分配25个请求量。并且通过虚线框来作为滑动窗口的大小,同时滑动窗口随着时间前移动,比如前面15s结束后,窗口滑动到15~45 这个区间,让后在新的窗口中需要重新统计数据,这种方式很好的解决了固定窗口算法的临界值问题。

令牌桶算法
-
令牌桶是对网络整体限制 + 速率限制的一个常用算法,对于每一个请求,都需要从令牌桶中获取一个令牌,如果没有获得令牌,则需要出发限流策略
-
下图是令牌桶案例,系统已一定速率(r token/sec)往固定容量的令牌桶中放入令牌,如果此时有客户端请求过来,则需要从令牌桶中拿到令牌以获得访问资格。

-
假设令牌生成速度是10 个/秒,也就等于QPS = 10 ,此时请求获取令牌的时候,存在三种情况:
- 请求速度大于令牌生成速度:持续一段时间桶中令牌消耗完,后续请求在进来会被限流
- 请求速度等于令牌生成速度:此时正好可以平稳运行
- 请求速度小于令牌生成速度:此时说明系统高并发不高,请求能被正常处理。
-
令牌桶算法中,有两个关键值,桶容量,令牌添加速率,两个值都必须低于系统能承载的最大QPS,
- 例如系统能承载的最大QPS是1000 QPS,当桶中是满的,此时突然有2000请求过来,也只能在一瞬间得到1000 的令牌数量,另外的1000 需要排队等待令牌的添加,也就是等到下一秒添加的1000令牌,这样就将2000 请求平均到了2秒内正好符合系统要求。
漏桶限流算法
- 漏桶算法主要作用是控制数据注入网络的速度,平滑网络上的突发流量。
- 漏桶算法如下图,在漏桶算法内容也需要维护一个容器,他会以很定的速率出水,不管添加水流的速度多快,漏桶流出的速度都是保持不变的,实际上消息中间件就使用了漏桶限流孙风,不管生产者请求量多大,消息的处理能力取决于消费者。

- 漏桶算法存在以下几种情况:
- 请求速度大于漏桶流水速度:也就是请求数超过服务端处理能力,将会触发限流策略
- 请求速度小于或者等于流水速度,也就是服务器处理能力正好满足客户的的请求量,将正常执行。
- 漏桶和令牌桶原理差不多,最大区别是漏桶无法处理短时间内的突发流量,漏桶限留算法是一种恒定速度的限流算法。
相关内容