sentinel的四种流控规则介绍( 二 ) _生活百科

单机阈值：12，这个表示我们访问最大阈值为12 ，但是第一次最大访问量为4，为什么是4呢，看下面公式
预热公式：阈值/coldFactor（默认值为3），经过预热时间后才会达到阈值。
预热时长：5，也就是说我们的请求会在五秒内单机阈值达到12的访问，比如第一次为4，后续在五秒内依次5/6/8/10 ，最后达到12的阈值
一般这种在秒杀或者电商节中会设置这样的流控规则，就是为了防止突然流量的增加导致系统的奔溃。
当我们设置完流控规则以后，我们就来看一下效果，我们刚才设置的order的接口，如果当我们在频繁的去访问order接口的时候，如果超过当前时间设定的阈值时，直接返回限流信息。

文章插图
在这里我们直接用浏览器疯狂的去刷新，是时候体验单身二十几年的手速了，当然也可以使用postman接口去试，我们这边手速比较快，直接用浏览器刷新，我们可以看到下面的曲线图：

文章插图
蓝色表示你拒绝的QPS ，绿色表示通过的QPS，我们可以看到蓝色成明显的下降趋势，而绿色成上升趋势，也可以通过右边的表格中看到，刚开始通过的只有四个，具体的有三个，后面通过慢慢增加，拒绝慢慢变少，这个就是我们Warm Up（预热）的作用了
四：排队等待我们现在来介绍最后一个流控规则的使用，排队等待会严格控制请求通过的间隔时间，让请求稳定且匀速的通过，可以用来处理间隔性突发的高流量，例如抢票软件，在某一秒或者一分钟内有大量的请求到来，而接下来的一段时间里处于空闲状态，我们希望系统能够在接下来的空余时间里也能出去这些请求，而不是直接拒绝。

文章插图
以固定的间隔时间让请求通过，当请求过来的时候，如果当前请求距离上一个请求通过的时间大于规则预设值，则请求通过，如果当前请求预期通过时间小于规则预设值，则进行排队等待，如果预期通过时间超过最大排队时间，直接拒绝请求。
Sentinel排队等待是漏铜算法+虚拟队列机制实现的，目前排队等待中不支持QPS>1000的场景

文章插图
我们对pay接口进行设置，一秒钟只处理一个QPS请求，其他的排队，如果超过15秒则直接拒绝
pay接口调整，这里我们给pay接口加上打印日志，方便我们看到具体效果

@GetMapping("/pay")public String pay() {//return "hello my name is pay ,wo shi boy";log.info("pay接口，请求线程为："+Thread.currentThread().getName());return testService.end();}

我们借助postman来进行调用，说明手速始终更不上工具，还是工具香，这里我们设置10个请求，没有间隔时间