大家好，大家可以叫我“小农”，这是我第68次更新的文章，点赞再看，养成习惯，点击左上角的蓝字关注我??木小农。前言在上一篇文章中，我们讲解了sentinel的基本介绍以及流控规则中直接快速失效的影响。有兴趣的可以看看之前的文章。今天，我们就为大家带来更详细的哨兵流控制规则介绍。今天的内容我们主要围绕四点进行介绍。流控方式：关联、链接。流量控制效果：热身、排队等候。这四点具体指的是什么？别着急，让我们一一详细介绍。首先，让我们从协会开始。首先启动项目：cloud-alibaba-sentinel-8006协会在官方介绍中说：当关联资源达到阈值时，将进行流量限制。这句话是什么意思？说得直接点，假设我们有两个接口A和B，当A关联到接口B，接口B的资源达到设定的阈值时，A的流量就会被限制。我们也可以这样理解，当我们的下游服务访问压力过大时，我们会拦截并限制上游服务的流量，比如：电商系统，当我们的订单系统超过容忍阈值时，我们会限制我们的支付模块流量.例如：当关联的订单接口达到我们设置的阈值时，限流支付接口访问。@Slf4j@RestControllerpublicclassTestController{@GetMapping("/pay")publicStringpay(){return"hellomynameispay,woshiboy";}@GetMapping("/order")publicStringorder(){返回“嗨，我叫订单，我是女孩”；}}支付接口添加流控规则。这里我们需要使用postMan工具来模拟并发访问，用它来测试我们下单接口的并发访问。这里的意思是25个线程每0.25秒运行一次。我们运行之后，访问支付界面可以看到如下信息。当我们并发访问下单界面的时候，这时候我们会访问支付界面。可以看到支付接口返回了限流信息链接。接下来我们看一下流控模式下的链路。link是指当某个接口过来的资源达到阈值时，开启限流，主要针对请求来自的微服务，粒度更细。比如在一个服务应用中，多个（payandorder）接口调用同一个服务中的方法（该方法必须用注解SentinelResource修饰），如果频繁请求pay接口，达到设定的阈值，此时次，如果我们再次请求下单接口，会限制调用同一个服务的下单接口。.testclass@ServicepublicclassTestService{//定义限流资源@SentinelResource("end")publicStringend(){return"endmethod";}}controllerclass@Slf4j@RestControllerpublicclassTestController{@AutowiredprivateTestServicetestService;@GetMapping("/pay")publicStringpay(){returntestService.end();}@GetMapping("/order")publicStringorder(){returntestService.end();}}配置项web-context-unify，这个配置的意思是根据不同的url限制链接流量，否则没有效果spring:application:name:cloudalibaba-sentinel-servicecloud:nacos:discovery:server-addr:localhost:8848sentinel:transport:#配置Sentinel地址，也就是我们的WEB界面dashboard:localhost:8080#Sentinel配置默认端口8719，占用的端口会自动从+1递增，直到找到未占用的端口。port:8719#配置为falseweb-context-unify:false我们访问支付接口和下单接口后，需要为end配置流控规则，即使用SentinelResource注解方法设置流控。所以这个时候，如果我们频繁访问订单接口，就会出现异常，直接抛出错误提示。这也是因为快速故障在链路上的直接反映。WarmUp参考文档：https://sentinelguard.io/zh-cn/docs/flow-control.html。WarmUp流量控制，也叫预热或者冷启动，会按照我们设定的规则慢慢释放流量，逐渐提高上限阈值，给系统一个反应时间，避免突然增加流量让系统不堪重负。主要是用来防止我们的系统长期处于稳定的流量访问状态，突然增加的流量会直接把系统资源占满。这里我们主要了解两个参数单机阈值：12，也就是说我们访问的最大阈值是12，但是第一次访问的最大次数是4，为什么是4呢？参见如下公式warm-up公式：threshold/coldFactor（默认值为3），warm-up时间后会达到阈值。预热时长：5，表示我们的请求会在五秒内达到阈值12，比如第一次是4，接着是五秒内5/6/8/10，最后达到阈值的是12一般秒杀或者电商节都会设置这样的流量控制规则，防止流量突然增加导致系统崩溃。我们设置好流控规则后，我们来看看效果。我们刚刚设置的下单接口，如果我们频繁访问下单接口，如果超过当前时间设置的阈值，会直接返回限流信息。这里我们直接使用浏览器疯狂刷新。是时候体验单身20多年的手速了。当然我们也可以使用postman接口来试试。我们这里的手速比较快，直接用浏览器刷新就可以了。见下图：蓝色代表你拒绝的QPS，绿色代表你通过的QPS，我们可以看到蓝色有明显的下降趋势，绿色有上升趋势，从右边的表格也可以看出，刚开始只有四遍，详细的有三遍。之后passes会逐渐增加，rejects会逐渐减少。这就是我们WarmUp（预热）排队等待的作用。下面介绍最后一个流控规则的使用。在队列中等待会严格控制请求通过的间隔时间，使请求能够稳定、匀速地通过。可以用来应对间歇性突发的高流量，比如抢票软件，在某一秒或一分钟内有大量请求到达。而接下来的一段时间会空闲，我们希望系统也能在接下来的空闲时间发出这些请求，而不是直接拒绝。让请求以固定的时间间隔通过。当请求到来时，如果当前请求与上一次请求的时间间隔大于规则预设的值，则请求通过。如果当前请求的预计通过时间小于规则预设值，则排队等待，如果预计通过时间超过最大排队时间，则直接拒绝该请求。Sentinel队列是通过铜泄漏算法+虚拟队列机制实现的。目前队列不支持QPS>1000的场景。我们设置pay接口每秒只处理一个QPS请求，其他都排队。如果超过15秒，则直接拒绝。支付界面调整，这里我们在支付界面添加一个打印日志，可以看到具体的效果。@GetMapping("/pay")publicStringpay(){//return"hellomynameispaywoshiboy";log.info("支付接口，请求线程为："+Thread.currentThread().getName());返回testService.end();}我们用postman调用，说明手速永远跟不上工具，或者工具香了。这里我们设置了10个没有间隔时间的请求。我们从下图中可以看出，对于我们的请求，是一个QPS请求。到这里总结一下，我们的流控规则就说完了，主要是针对不同的规则做不同的设置，以满足我们不同的业务场景，可能会有一点点麻烦，但是如果自己操作的话，就会觉得原来是是这样的。有兴趣的朋友可以自己尝试一下。源代码已上传。只有去做，你才能感受到快乐。快点试试吧。
