Sentinel流控规则

1、基本介绍

资源名：唯一名称，默认请求路径(如：http://localhost:8089/testA)

针对来源：Sentinel可以针对调用者进行限流，填写微服务名，指定对哪个微服务进行限流 ，默认default(不区分来源，全部限制)

阈值类型/单机阈值：

1. QPS(每秒钟的请求数量)【挡在门外】：当调用该接口的QPS达到了阈值的时候，进行限流；
2. 线程数【关门打狗】：当调用该接口的线程数达到阈值时，进行限流

是否集群：不需要集群

流控模式：

1. 直接：接口达到限流条件时，直接限流
2. 关联：当关联的资源达到阈值时，就限流自己
3. 链路：只记录指定链路上的流量（指定资源从入口资源进来的流量，如果达到阈值，就可以限流）[api级别的针对来源]

流控效果

1. 快速失败：直接失败
2. Warm Up：即请求 QPS 从 threshold / 3 开始，经预热时长逐渐升至设定的 QPS 阈值
3. 排队等待

2、流控模式

2.1、直接流控模式

2.1.1、阈值类型QPS【拦截在门外】

通过上图1给testA添加QPS为1的流控设置，当一秒钟内请求超过1QPS请求数就会直接给前台报错

默认的前台报错

Blocked by Sentinel (flow limiting)

2.1.2、阀值类型之线程数【关门打狗】

将上面的SQP阈值改为线程数之后，在一秒钟内不管怎么点击请求都不会出现前台报错，通过如下控制器接口来进行演示

给流控的接口添加睡眠0.8秒时间，重启项目

@GetMapping("/testA")
public String testA()
{
    try {
        TimeUnit.MILLISECONDS.sleep(800);
    }catch (InterruptedException e) {
        e.printStackTrace();
    }
    return "------testA";
}

测试：通过多次访问/testA接口查看报错信息

2.2、关联流控模式

当关联的资源达到阈值时，就限流自己

当与A关联的资源B达到阀值后，就限流A自己，B惹事，A挂了

当关联资源/testB的qps阀值超过1时，就限流/testA的Rest访问地址，当【关联资源】达到阈值后限制配置好的【资源名】

使用场景：订单服务关联第三方支付接口，当支付接口过多的时候导致快瘫痪时，那么就限制我们的下单服务（限流）

1、postman模拟并发密集访问testB

需要将上一次修改控制器的代码还原，不需要再使用测试线程数的，都使用SQP

@GetMapping("/testA")
public String testA()
{
    return "------testA";
}

在postman中开始并发测试的时候，在浏览器访问/testA控制器接口查看是否被关联前台报错，当postman并发完成再访问A又可以正常的连接

Blocked by Sentinel (flow limiting)

2.3、链路流控模式

只记录指定链路上的流量（指定资源从入口资源进来的流量，如果达到阈值，就可以限流）[api级别的针对来源]

同样的测试方法，使用上一次的postman模拟并发请求testB，每秒超过阈值1就会限制A

3、流控效果

3.1、默认的快速失败

直接抛出异常

Blocked by Sentinel (flow limiting)

3.2、Warm Up 预热/冷启动方式

官网介绍地址：https://github.com/alibaba/Sentinel/wiki/流量控制

Warm Up（RuleConstant.CONTROL_BEHAVIOR_WARM_UP）方式，即预热/冷启动方式。当系统长期处于低水位的情况下，当流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动"，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮

当令牌桶饱和的时候，基于 Guava 的计算上，我们可以推出下面两个公式:

rate(c)=m*c+ coldrate

其中，rate 为当前请求和上一个请求的间隔时间，而 rate 是和令牌桶中的高于阈值的令牌数量成线形关系的。cold rate 则为当桶满的时候，请求和请求的最大间隔。通常是 coldFactor * rate(stable)。

默认 coldFactor 为 3，即请求 QPS 从 threshold / 3 开始，经预热时长逐渐升至设定的 QPS 阈值。

通常冷启动的过程系统允许通过的 QPS 曲线如下图所示：

设置Warm Up

默认 coldFactor 为 3，即请求QPS从(threshold / 3) 开始，经多少预热时长才逐渐升至设定的 QPS 阈值。

案例，阀值为10+预热时长设置5秒。

系统初始化的阀值为10 / 3 约等于3,即阀值刚开始为3；然后过了5秒后阀值才慢慢升高恢复到10

通过postman高并发发送请求再查看Sentinel的实现监控曲线图

上面设置的SQP是10，也就是1秒钟可以处理10个请求，那么通过postman发送并发请求，一下子就达到了最高单机阈值10，就被预热效果给拦住了，过了预热时间基本都是最大阈值内的请求，如果超过阈值就会前台报错

使用场景

如：秒杀系统在开启的瞬间，会有很多流量上来，很有可能把系统打死，预热方式就是把为了保护系统，可慢慢的把流量放进来，慢慢的把阀值增长到设置的阀值。

3.3、排队等候

匀速排队，让请求以均匀的速度通过，阀值类型必须设成QPS，否则无效。

设置含义：/testA每秒1次请求，超过的话就排队等待，等待的超时时间为20000毫秒。

在请求A接口上添加日记打印

log.info(Thread.currentThread().getName() + "...TestA");

postman设置并发线程

观察日记输出（查看等待输出时间）

输出的时间是随机的，只要看到A后面的资源确实是等待了就可以

2022-09-28 10:27:36.051  INFO 9972 --- [io-8401-exec-10] c.z.s.controller.FlowLimitController     : http-nio-8401-exec-10...TestA
2022-09-28 10:27:38.268  INFO 9972 --- [nio-8401-exec-1] c.z.s.controller.FlowLimitController     : http-nio-8401-exec-1...TestA
2022-09-28 10:27:40.469  INFO 9972 --- [nio-8401-exec-4] c.z.s.controller.FlowLimitController     : http-nio-8401-exec-4...TestA
2022-09-28 10:27:42.653  INFO 9972 --- [nio-8401-exec-6] c.z.s.controller.FlowLimitController     : http-nio-8401-exec-6...TestA
2022-09-28 10:27:44.835  INFO 9972 --- [nio-8401-exec-9] c.z.s.controller.FlowLimitController     : http-nio-8401-exec-9...TestA
2022-09-28 10:27:47.055  INFO 9972 --- [io-8401-exec-10] c.z.s.controller.FlowLimitController     : http-nio-8401-exec-10...TestA
2022-09-28 10:27:49.255  INFO 9972 --- [nio-8401-exec-1] c.z.s.controller.FlowLimitController     : http-nio-8401-exec-1...TestA
2022-09-28 10:27:51.467  INFO 9972 --- [nio-8401-exec-4] c.z.s.controller.FlowLimitController     : http-nio-8401-exec-4...TestA
2022-09-28 10:27:53.653  INFO 9972 --- [nio-8401-exec-6] c.z.s.controller.FlowLimitController     : http-nio-8401-exec-6...TestA
2022-09-28 10:27:55.839  INFO 9972 --- [nio-8401-exec-9] c.z.s.controller.FlowLimitController     : http-nio-8401-exec-9...TestA