Sentinel流控规则
1、基本介绍
资源名：唯一名称，默认请求路径(如：http://localhost:8089/testA)
针对来源：Sentinel可以针对调用者进行限流，填写微服务名，指定对哪个微服务进行限流 ，默认default(不区分来源，全部限制)
阈值类型/单机阈值：
- QPS(每秒钟的请求数量)【挡在门外】：当调用该接口的QPS达到了阈值的时候，进行限流；
- 线程数【关门打狗】：当调用该接口的线程数达到阈值时，进行限流
是否集群：不需要集群
流控模式：
- 直接：接口达到限流条件时，直接限流
- 关联：当关联的资源达到阈值时，就限流自己
- 链路：只记录指定链路上的流量（指定资源从入口资源进来的流量，如果达到阈值，就可以限流）[api级别的针对来源]
流控效果
- 快速失败：直接失败
- Warm Up：即请求 QPS 从 threshold / 3 开始，经预热时长逐渐升至设定的 QPS 阈值
- 排队等待
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设置并发线程
观察日记输出（查看等待输出时间）文章来源：https://www.toymoban.com/news/detail-421284.html
输出的时间是随机的，只要看到A后面的资源确实是等待了就可以文章来源地址https://www.toymoban.com/news/detail-421284.html
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
到了这里，关于Sentinel流控规则的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
