文章目录
- 1、簇点链路
- 2、流控入门案例
- 3、流控模式:关联模式
- 4、流控模式:链路模式
- 5、流控效果:warm up
- 6、限流效果:排队等待
- 7、热点参数限流
1、簇点链路
簇点链路就是项目内的调用链路(controller -> servcie -> mapper ),链路中被监控的每个接口就是一个资源。
默认情况下sentinel会监控SpringMVC的每一个端点(Endpoint),Endpoint可以理解为controller中的每一个方法,每一个端点(Endpoint)就是调用链路中的一个资源。
流控、熔断等都是针对簇点链路中的资源来设置的。
点击流控,可以新增流控规则:
QPS为1,即每秒只允许1次请求,超出的请求会被拦截并报错。
2、流控入门案例
需求:给 /order/{orderId}这个资源设置流控规则,QPS不能超过 5。然后利用jemeter测试。
- 点击流控,设置QPS
- 打开Jemter,添加测试计划,右键start
- 查看结果树,可以看到确实每秒最多5个请求
- 查看sentinel控制台
3、流控模式:关联模式
在添加限流规则时,点击高级选项,可以选择三种流控模式:
- 直接:统计当前资源的请求,触发阈值时对当前资源直接限流,也是默认的模式(入门案例里的效果)
- 关联:统计与当前资源相关的另一个资源,触发阈值时,对当前资源限流
- 链路:统计从指定链路访问到本资源的请求,触发阈值时,对指定链路限流
流控模式:关联
关联模式的使用场景如:比如用户支付时需要修改订单状态,同时用户要查询订单。但查询和修改操作会争抢数据库锁,二者为竞争关系。
很明显,我需要优先满足支付,即修改订单状态优先级更高,因此当修改订单业务触发阈值时,需要对查询订单业务限流。直白讲就是,二者竞争,超过阈值时,优先级低的被限流,避免影响优先级高的。
当/write资源访问量触发阈值时,就会对/read资源限流,避免影响/write资源。关联资源是优先级高的,在优先级低的上面添加限流规则!
需求:
- 在OrderController新建两个端点:/order/query和/order/update,无需实现业务
- 配置流控规则,当/order/ update资源被访问的QPS超过5时,对/order/query请求限流
- 写两个测试接口资源
@GetMapping("/order/query")
public String queryOrder(){
return "查询订单成功";
}
@GetMappinng("/order/update")
public String updateOrder(){
return "更新订单成功";
}
- 很明显,query资源优先级低,在它上面添加流控规则
- jmeter模拟请求/order/update,QPS设置10,按图中设置,这100秒内,update的QPS均大于阈值5
- 访问/order/query,可以看到已被限流
- 但/order/update资源却不被限制
对关联模式做个总结就是;
4、流控模式:链路模式
只针对从指定链路访问到本资源的请求做统计,判断是否超过阈值
例如有两条请求链路:
- /test1 到 /common
- /test2 到 /common
如果只希望统计从/test2进入到/common的请求,则可以这样配置:
需求:
- 有查询订单和创建订单业务,两者都需要查询商品。
- 针对从查询订单进入到查询商品的请求统计,并设置限流,QPS<2。
访问资源"查询商品方法",以上就有两条链路:
- 入口1:查询订单/order/query—>查询商品queryGoods
- 入口2:创建订单/order/save —> 查询商品queryGoods
这里需要对queryGoods添加链路模式限流,从/order/query进入queryGoods方法的QPS限制必须小于2.
但注意默认只有controller中的方法会被监控,Service层的queryGoods方法没有被监控,也就不能配置限流规则,要标记其它方法,需要利用@SentinelResource注解:
@SentinelResource("goods")
public void queryGoods() {
System.err.println("查询商品");
}
此外:Sentinel默认会将Controller方法做context整合,认为是由同一个根链路发展来的子链路,从而导致链路模式的流控失效,因此需要修改application.yml,添加配置:
spring:
cloud:
sentinel:
web-context-unify: false # 关闭context整合
- 接口与方法资源代码展示
public class OrderService{
@SentinelResource("goods")
public void queryGoods(){
System.out.println("查询商品");
}
}
@Resource
private OrderService orderService;
@GetMapping("/order/query")
public String queryOrder(){
orderService.queryGoods(); //查商品,形成一个链路
System.out.println("查询订单");
return "查询订单成功";
}
@GetMapping("/order/save")
public String saveOrder(){
orderService.queryGoods(); //查商品,形成一个链路
System.out.println("新增订单");
return "新增订单成功";
}
- 访问下save和query接口,查看sentinel簇点链路:
- 两个goods都一样,随便选一个点击新增流控按钮
- 打开Jmeter做测试,QPS我设为200/50 = 4 > 2,发送query和save请求:
- 可以看到save不受影响:
- 但query的链路我设置了限流,可以看到每秒总有4-2=2个请求失败:
关于流控模式的总结:
5、流控效果:warm up
流控效果是指请求达到流控阈值时应该采取的措施,包括三种:
- 快速失败:达到阈值后,新的请求会被立即拒绝并抛出FlowException异常。是默认的处理方式。
- warm up:预热模式,对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化,从一个较小值逐渐增加到最大阈值。
- 排队等待:让所有的请求按照先后次序排队执行,两个请求的间隔不能小于指定时长
就像剧烈运动前慢跑热身一样,服务器刚启动时,不能直接打满到最大QPS,这就是warm up的限流效果:
warm up也叫预热模式,是应对服务冷启动的一种方案。请求阈值初始值是 threshold / coldFactor,前者为最大QPS,后者为冷启动因子。持续指定时长后,逐渐提高到threshold值。而coldFactor的默认值是3.
例如,我设置QPS的threshold为10,预热时间为5秒,那么初始阈值就是 10 / 3 ,也就是3,然后在5秒后逐渐增长到10.
需求:
- 给/order/{orderId}这个资源设置限流,最大QPS为10。
- 利用warm up效果,预热时长为5秒
添加流控规则:
Jmeter设置QPS为10,start发起请求:
可以看到刚开始,10个请求只成功3个:
随着时间的推移,达到10,则全部请求都能成功:
查看监控面板:
6、限流效果:排队等待
当请求超过QPS阈值时,快速失败和warm up 会拒绝新的请求并抛出异常。而排队等待则是让所有请求进入一个队列中,然后按照阈值允许的时间间隔依次执行。当预期等待时长超过timeout时间,则请求才会被拒绝。
假设QPS=5,即每200ms处理一个请求,比如设置timeout=2000。如上图,预计等待时间线上排队着一个个请求,最后一个绿点的预计等待时间刚好为2000ms == timeout,此时再来一个需求,预计等待时间就大于了timeout,这个需求就会被拒绝。
这种限流效果,其实起到了一个流量整形的效果,不管client来的需求每秒有多少个,进入队列后再出来,就都是一秒QPS个:
需求:
给/order/{orderId}这个资源设置限流,最大QPS为10,利用排队的流控效果,超时时长设置为5s
- 新增流控规则
- Jmeter中设置QPS为15,如果是前两种限流效果,则每秒的15个请求中,成功10个,失败5个。按排队的限流效果,应该是刚开始多出的5个不会失败
- 查看监控面板,可以看到每秒10个请求,且多出来的5个不是全部拒绝,而是排队时间预计超过5s的才拒绝
流控效果小结:
7、热点参数限流
之前的限流是统计所有请求,然后判断QPS是否超过阈值,如下图,即QPS为4:
而热点参数限流则是分别统计参数值相同的请求,然后判断是否超过阈值。
配置示例为:
含义是:对hot这个资源的0号参数(第一个参数)做统计,每1秒相同参数值的请求数不能超过5
但此时有个问题,比如商品001没人看,商品002火爆,现在限制商品id相同的请求,每秒不能大于5个,则001,002都没一竿子打死了,001的QPS用不完,002的QPS不够用。针对这种场景,可以对部分参数设置例外配置:
这个配置的含义就是:对0号的long类型参数限流,每1秒相同参数的QPS不能超过5。但如果参数值为100或者101,则可以例外:
- 如果参数值是100,则每1秒允许的QPS为10
- 如果参数值是101,则每1秒允许的QPS为15
需求:
- 给/order/{orderId}这个资源添加热点参数限流,规则如下:
- 默认的热点参数规则是每1秒请求量不超过2
- 给102这个参数设置例外:每1秒请求量不超过4
- 给103这个参数设置例外:每1秒请求量不超过10
就是说,添加热点参数限流,我们之前的controller中的那一个个方法,热点限流不再认识,需要额外加@SentinelSource注解。
- 修改代码,添加@SentinelSource注解
@SentinelSource("hot") //此时,这个资源(方法)就有两个名字了,之前的/order/{orderID}和hot
@GetMapping("{orderId}")
public Oeder queryOrderByUserId(@PathVariable("orderId") Long orderId){
return orderService.queryOrderById(orderId);
}
- 重启服务,可以看到簇点链路中多了一个hot(别直接在后面点击【+热点】来配置,这里没高级选项)
- 切到热点规则侧边栏,新增热点限流规则
- 使用Jmeter模拟并发,QPS设置为500/100 = 5,三个取样器中分别请求101、102、103三个orderId
- 查看Jmeter结果树或者Sentinel的监控面板
最后,这个热点限流是根据传参来进行更细粒度的限流,且传参只支持基本数据类型。要是没有这种细粒度需求,走前面的正常限流模式 + 限流效果即可。