sentinel流控规则
作者:互联网
1.名词解释
资源名:唯一名称,默认请求路径
针对来源:Sentinel可以针对调用者进行限流,填写微服务名,默认default(不区分来源)
阈值类型/单机阈值:
- QPS(每秒钟的请求数量):当调用该API的QPS达到阈值的时候,进行限流
- 线程数:当调用该API的线程数量达到阈值的时候,进行限流
是否集群:当前不需要集群
流控模式:
- 直接:API达到限流条件时,直接限流
- 关联:当关联的资源达到阈值时,就限流自己
- 链路:只记录指定链路上的流量(指定资源从入口资源进来的流量,如果达到阈值,就进行限流)(API级别的针对来源)
流控效果:
- 快速失败:直接失败,抛异常
- Wam Up:根据codeFactor(冷加载因子,默认3)的值,从阈值/codeFacotor,经过预热时长,才达到设置的QPS阈值
- 排队等待:匀速排队,让请求以匀速的速度通过,阈值类型必须设置为QPS,否则无效
2.QPS限流
单机阈值设定为1,代表的是当前这个接口1秒只能被访问一次,超过这个阈值,就会被Sentinel阻塞,现在默认为直接失败
3.并发线程数限流
QPS表示每秒最多有多少个请求可以进入到此方法
并发线程数表示同时进入到此方法的线程最多有多少个,比如我现在阈值设置为5,如果此时我的/testA执行需要10秒,那么最多有5个线程可以进入到此方法,超过5个的线程都会被拒接
修改代码:
@RestController public class FlowLimitController { @GetMapping("/testA") public String testA() throws InterruptedException { System.out.println("进入A方法"); Thread.sleep(30000); // 休眠30s达到阻塞的效果 return "-----testA"; } @GetMapping("/testB") public String testB() { return "-----testB"; } }
不断刷新浏览器,当请求超过5个的时候会抛出异常,观察后台打印最多只有5个输出
4.关联限流
官方解释:当关联的资源达到阈值时,就限流自己。通俗解释来说,比如那我们的程序,现在有testA接口和testB接口,当A关联的资源B达到阈值后,就限流自己,也就是B到达阈值,限流A本身。比如一个电商系统中,支付系统达到阈值,就限流下订单系统。
添加流控规则:当关联资源/testB的qps阈值超时1时,就限流/testA的Rest访问地址,当关联资源到阈值后限制配置好的资源名
验证结果当testB到达阈值后,限流testA
5.链路
链路流控模式指的是,当从某个接口过来的资源达到限流条件时,开启限流,它的功能有点类似于针对来源配置项,区别在于:针对来源是针对上级微服务,而链路流控是针对上级接口,也就是说它的粒度更细。比如在一个微服务中,两个接口都调用了同一个Service中的方法,并且该方法用SentinelResource(用于定义资源)注解标注了,然后对该注解标注的资源(方法)进行配置,则可以选择链路模式。
具体演示:
增加一个service类:
import com.alibaba.csp.sentinel.annotation.SentinelResource; import org.springframework.stereotype.Service; @Service public class TestService { // 定义限流资源 @SentinelResource("common") public String common(){ return "common"; } }
然后更改接口调用这个Service方法:
RestController public class FlowLimitController { @Autowired TestService testService; @GetMapping("/testA") public String testA() throws InterruptedException { testService.common(); return "-----testA" ; } @GetMapping("/testB") public String testB() { testService.common(); return "-----testB"; } }
修改yml文件:
spring: cloud: sentinel: # 配置为false,不配置链路规则无法生效 web-context-unify: false
增加链路流控规则:
最后频繁访问testB正常方法,频繁访问testA则出现异常
6.预热
概念:Warm Up方式,当流量突然增加时直接把系统拉升到高水位可能会瞬间把系统压垮。通过"冷启动",让流量缓慢增加,在一定时间内逐渐增加到阈值上限,给冷系统一个预热的时间,避免系统被压垮的情况。
预热公式:阈值/coldFactor(默认值为3),经过预热时间后才会达到阈值。
使用场景:一般秒杀系统中会有这样的流控设置,为了防止秒杀瞬间造成系统崩溃。
冷启动的过程系统允许通过的QPS曲线如下图:
增加预热规则:
默认coldFactor为3,当发起请求的时候QPS从(阈值/3)开始,经过多长预热时长才逐步升至设定的QPS阈值,当前阈值设置为10,预热时长设置为5秒。
最终的效果,系统初始化时阈值/3约等于3,即阈值在此时为3,经过5秒后阈值才慢慢升高到10
7.排队等待
概念:匀速排队方式会严格控制请求通过的间隔时间,也就是让请求以均匀的速度通过,对应的是漏桶算法。这种方式主要用于处理间隔性突发的流量,例如消息队列。想象一下这样的场景,在某一秒有大量的请求到来,而接下来的几秒则处于空闲状态,我们希望系统能够在接下来的空闲期间逐渐处理这些请求,而不是在第一秒直接拒绝多余的请求(削峰填谷)。
匀速器:它的中心思想是,以固定的间隔时间让请求通过。当请求到来的时候,如果当前请求距离上个请求通过的时间间隔不小于预设值,则让当前请求通过。否则,计算当前请求的预期通过时间,如果该请求的预期通过时间小于规则预设的 timeout 时间,则该请求会等待直到预设时间到来通过(排队等待处理);若预期的通过时间超出最大排队时长,则直接拒接这个请求。
Sentinel 匀速排队等待策略是漏桶算法结合虚拟队列等待机制实现的。
注意:匀速排队模式暂时不支持 QPS > 1000 的场景。
流控规则配置:
通过打印时间可以观察到每个请求通过的时候大概都在1s左右,如果排队等待中的请求超过20个,那么后续请求会被拒绝
标签:请求,阈值,testA,限流,testB,流控,规则,sentinel,QPS 来源: https://www.cnblogs.com/ZT-666/p/16294476.html