这是我参与「掘金日新计划 · 8 月更文挑战」的第11天,点击查看活动详情
流控规则
上一篇我们使用的都是一些基本的流控规则,在sentinelDashboard 中添加时有一个高级选项,高级选项中包含流控模式和流控效果,其中有分别包含 直接 关联 和链路 以及流控效果中的 快速失败,排队等待以及warm up等。
下面我们首先看看流控模式的三个选项
直接
:也就是默认的规则在调用资源达到设置阈值后直接被流控抛出异常。
关联
:当两个资源之间具有资源争抢或者依赖关系时,两个资源就有了关联。举一个简单的例子就是同时操作一张表的数据,查询表中的数据会影响,插入表中数据的速度,但是为了保证我们插入数据的可用性减少两个操作争抢资源带来的开销影响到系统的吞吐。我们就可以给插入数据的创建流控关联到查询数据的接口,也就是当我们的插入出发流控规则后我们的查询会被限制(直接失败等)。
在这个场景中肯定是插入订单的优先级高于查询的
我们先创建一下流控规则(给select 添加流控但是是由insert触发)
这里我们需要使用一下 postman 跑一下insert(计划跑了100次)接口 我们同时在浏览器请求查询就可以看到因为insert 我们的查询请求被流控了。
链路
:根据调用链路入口进行限流。资源之间调用关系 ,相互会构成一个树并且 sentinel也是支持方法流控的。
也就是A接口调用公共方法B,同时C也调用公共方法B。现在对方法B实现流控当A调用达到流控时阈值时将 C流控掉让A正常访问。
下面我们就演示一下 先准备一个services
@Service
public class TestServices {
@SentinelResource(value = "getinfo",blockHandler = "blockHandlerGetInfo")
public String getinfo() {
return "获取info";
}
//使用SentinelResource 注解之后统一的流控结果处理类会失效需要手动加一个业务的处理方法
public String blockHandlerGetInfo(BlockException e){
return "流控限制";
}
}
注意:还需要打开 web-context-unify: false
默认时true 是不维护链路树的
这两个方法都调用 getinfo
@RequestMapping("select")
public R select(){
String str= testServices.getinfo();
return R.ok().message("查询成功");
}
@RequestMapping("insert")
public R insert(){
testServices.getinfo();
return R.ok().message("插入成功");
}
先描我们创建一下流控规则 在链路中可以看到我们这个方法
我们还是流控 select
下面直接频繁请求select接口会发现会被限制,但是insert没有问题
流控效果
- 快速失败:默认效果超出流控规则的请求都会直接返回失败。
- Warm Up:当系统流量在一个时间段直接达到峰值瞬间冲垮系统,为了避免这样我们就通过warm up让流量缓慢增加,在一定的时间内逐渐增加到阈值上线,以系统一个预热时间,避免系统被冲垮。(有点像防止缓存击穿场景)。这里有个概念是
冷加载因子:默认是3 然后是从 阈值/3 一直到阈值。
- 排队等待:就是排队达到阈值之后后面的请求进行排队可以设置一个超时时间(即就是这个超时时间内 如果系统把之前的处理完了就继续处理后面的,没有处理完且超时时间已经过了就返回失败)
下面我们来演示下 warm up
下面 我们使用 postman 跑一下100个请求,并不是一下子就10而是缓慢增加到
实践是检验真理的唯一准则,感兴趣的可以去试试呀!明天见咯 😃😃😃😃