Sentinel实战(三)、流控规则之流控效果及流控小结

一、流控规则：流控效果

流控效果有当前支持三种：直接失败、预热（warm up）、排队等待。
直接失败没什么可说的，下面主要围绕预热和排队等待展开。

一）、流控效果：预热

主要针对开启活动之前，系统流量是比较低的，比如秒杀活动即将开始后，系统访问量突增，可能把系统压垮，增加预热流控规则，是个比较好的方案。

1、概念含义

预热就是下图流控效果里，Warm Up ；即 预热/冷启动方式；这种方式用于系统长期处于低流量的情况，当流量突然激增，由于流量的突然激增可能瞬间会把系统压垮。通过这种“冷启动”的方式，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给系统一个缓冲的时间，通过这种冷启动的方式避免系统被压垮。
预热公式为 单机阈值/coldFactor（预热因子，默认为3），经过预热时间后，才会达到阈值。

设置参数后的具体含义通过案例阐述。

2、案例

这种预热流控的设置，通常的场景类如 秒杀，主要是为了防止瞬间激增的流量打垮系统。关于设置秒杀的代码及配置如下：

端口9101服务，秒杀接口代码段：

   /*** 秒杀活动，设置预热的流控规则*/@GetMapping("/secKill")public String secKill() throws InterruptedException {log.info("---secKill---流控模式为 预热");Thread.sleep(200);return "ok";}

yaml文件配置内容如下：

server:port: 9101
spring:application:name: nacos-consumercloud:nacos:discovery:server-addr: 192.168.0.101:80sentinel:transport:dashboard: localhost:8080   port: 8720   web-context-unify: falsemanagement:endpoint:web:exposure:include:'*'
service-url:nacos-user-service: http://nacos-provider

主启动类添加服务发现注解：

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient;
import org.springframework.cloud.client.loadbalancer.LoadBalanced;
import org.springframework.context.annotation.Bean;
import org.springframework.web.client.RestTemplate;@EnableDiscoveryClient
@SpringBootApplication
public class NacosConsumer9101Application {public static void main(String[] args) {SpringApplication.run(NacosConsumer9101Application.class, args);}}

启动服务访问，初始化sentinel的簇点链路，访问链接：http://localhost:9101/secKill

在资源 /secKill添加流控规则。

流控规则设置

该流控规则设置含义：当单机 QPS达到10，预热时长是5秒。
在这 5s内流量有个流量突增的过程，预热因子默认是3，根据预热公式，当QPS超过单机阈值的三分之一，即超过3时，就开始限流，随着5s的推移，第一秒可能是3，第二秒是4，第5s是10。这个预热的流控效果，其实指的就是系统处理流量突增的过程。

测试结果

流控规则设置完之后，并发线程数设置为10，持续2min，开始进行压测【工具jmeter】：

观察资源流量的实时监控情况，可看出QPS超过10 之后，拒绝QPS那列有了数值，说明被限流了。再看下压测接口响应失败jmeter的显示内容，提示被限流了：

二）、流控效果：排队等待

1、概念含义

匀速排队的方式，可以严格控制请求通过的时间间隔，就是让请求匀速通过，对应算法为漏桶算法。
这种方式主要用来处理间隔性突发流量，类似消息队列，在某一秒大量请求袭来，而后处于空闲状态，可以让空闲时间处理先前这大批量的请求，而不是第一时间拒绝多余的请求。
类似一个匀速器，在固定时间间隔让请求通过：

• 若当前请求距离上个通过的请求通过的时间间隔大于预设值，则请求通过。
• 否则，若当前请求的预期时间<规则预设的超时时间，那当前请求就要等待直到大于预设值则请求通过。
• 若预期的通过时间超过最大排队时长，则直接拒绝这个请求。

Sentinel的匀速排队等待流控效果，是基于漏桶算法结合虚拟队列等待机制实现的。
注意⚠️：匀速排队模式暂时不支持QPS超过1000的场景。

2、案例

比如这个例子：QPS单机阈值超过5，则进行排队等待，在15s内 ，1s处理5个，超过15s 还没处理完的其他请求，则视为超时。

流控规则设置

测试及结果

压测并发量10，持续2min，访问链接：http://localhost:9101/waiting
观察Sentinel流量监控平台的变化以及指标统计情况：

前半段超时时间设置的15s ，可以看到没有被限流的请求。
后半段蓝色折线图，流控规则排队等待的超时时间调整为1s，观察图表可以看到超过1s的请求视为超时，还没处理的请求都被限流了：

查看响应失败的接口响应信息展示：

二、流控规则实际使用总结

关于流控规则，主要围绕 ：阈值类型，流控模式，流控效果这三个维度，做的测试以及释义，当然最主要还是实际应用场景，下面是具体阐述这三个维度组合起来，分别适合哪些特点的场景，以及实际对应的业务场景案例， 还有配置时注意事项。

一）、阈值类型、流控模式、流控效果组合及适用场景

其实在上一篇和本文都已陆续说过，但比较零散，还是需要单独梳理一下，算是巩固加强印象了，希望能对读者在工作中有帮助；组合使用大致梳理出6个点。

1、阈值为QPS 、流控模式为直接、快速失败[的流控效果]

1）规则适用的业务特点

直接限制单个资源每秒请求量，超出的请求会被立即拒绝。这种规则可快速响应流量突发状况，能有效保护资源不被过度请求。

2）适用场景

• 验证码发送，防止恶意刷验证码的行为，可设置QPS阈值，同样超出阈值则直接拒绝。

3）配置时要注意的事项

具体设置的值要参考日常流量以及历史高峰流量倍数作压测指标，进行摸底压测，大促期间可以此摸底性能为阈值上限，进行设置，注意⚠️，绝不能高于摸底上限，否则无法起到保护作用，也不能太低，否则会影响正常业务。

2、阈值为QPS 、流控模式为关联、快速失败[的流控效果]

1）规则适用的业务特点

根据关联资源的QPS阈值，来控制当前资源的访问。当关联资源达到阈值，则对当前资源进行限流，通过关联关系间接保护关联资源不被压垮。

2）适用场景

• 创单和支付，创单之后，会调用支付接口，可以创建流控规则，关联资源为支付，设置关联资源阈值，当支付达到该阈值，则对创单接口进行限流。
• 订单系统中，创单和扣减库存也是一样的道理，避免卖超的方案之一，可以将扣减库存设为关联资源，当其QPS过高，超过阈值，依然要对创单接口进行限流。
• 支付系统中，支付接口和用户的资金账户 同理，可将用户的资金账户设为关联资源，当QPS过高，超过其实际承载流量的阈值，这时支付的性能会受到影响，此时可对支付接口进行流控。

3）配置时要注意的事项

要准确识别到关联资源，确保关联的合理性，另外还要注意的点是，关联资源的阈值设置要考虑两个资源之间的业务逻辑关系。

一般作为关联资源的，可以是公共服务等设置为关联资源 或者 特点是业务链路的后置服务，如果该资源实际性能较差且不在核心链路上，可以设置为关联资源，以此来保护该资源不被压垮。
如果该资源在核心链路上，除了让其成为关联资源，还要进行优化，优化性能指标至少要跟核心链路起始资源性能对齐，如果内部涉及到第三方接口调用，无法提升性能，则要考虑技术方案的调整，比如看哪些业务数据可以前置操作，串行调用调整为并发编程，同步改为异步方式实现。具体还是要结合实际业务作技术方案调整的决策。
而且，被设置为关联的资源，通常是该资源容易遇到性能瓶颈，就是性能不足与当前系统流量高峰或历史高峰时的需求相匹配，所以要设置为关联资源以此来保护其功能保持在正常水平。

3、阈值为QPS 、流控模式为链路、快速失败[的流控效果]

1）规则适用的业务特点

只对指定链路的资源请求进行QPS限制，即当链路入口资源达到阈值，则对其进行限流。能精确控制特定调用链路流量，有效避免因该链路流量过大影响系统性能。

2）适用场景

• 微服务架构中，某个服务可能涉及多个调用链路，若其中一条调用链路过大，可对该链路进行流控。场景比如 商品详情服务调用 加车服务，再调用结算服务这条调用链路，可以设置链路QPS阈值，超过则拒绝请求。
• 某个接口有不同的调用来源，可对该特定来源的调用链路进行流控，比如结算创单资源接口，可以是普通商品调用链路的一个节点，也可以是促销如秒杀调用链路的一个节点，为了保护系统资源能正常服务，可以对秒杀等其他大流量的调用链路做链路流控配置。

3）配置时要注意的事项

明确要配置的链路规则，指定受流控的链路。同时，考虑链路阈值的动态变化，做出及时调控。

4、阈值为QPS 、流控模式为直接、Warm Up[的流控效果]

1）规则适用的业务特点

系统启动初期QPS较低，随时间推移，阈值逐渐增加到日常流量最大值，流控效果为预热模式，启动阶段可让系统有个流量适应过程。

2）适用场景

新上线服务，系统初始化阶段性能不稳定，可通过设置预热流控效果，能有效避免大量流量短时间涌入系统造成崩溃；比如服务版本升级重启，防止大量请求在瞬间击垮系统，可设置流控效果为预热模式。

促销活动，在活动开始之前，就会有一个流量持续增加的过程，比如秒杀前，系统流量会在段时间内迅速增加，所以要设置预热，即提前限流，会超过系统负载导致崩溃无法正常工作，对此场景，可设置QPS阈值，超出直接拒绝。

3）配置时要注意的事项

要合理设置预热时间和初始阈值，预热时间过短无法起到预热效果，过长则影响系统响应速度。

5、阈值为QPS 、流控模式为直接、排队[的流控效果]

1）规则适用的业务特点

请求超过QPS阈值，会进入排队等待， 从队列中匀速取出请求进行处理，可保证请求有序处理。此流控效果，适合非核心业务，比如某些营销类（不是全部哈，根据当前阶段业务重要程度，杠精请口下留情哈），对实时性要求不高，甚至可以滞后或降级处理的业务。

2）适用场景

• 文件上传接口，对该操作的响应时间要求相对较低，可接受一定时间内的等待。当上传请求过多时，超出阈值的请求进入队列进行排队等待，然后按顺序匀速处理(类比mq的削峰填谷)。
• 处理批量任务的时候，比如批量导入商品数据，可采用排队等待的流控效果，保证数据处理的有序性。

3）配置时要注意的事项

设置合理队列长度和超时时间，队列长度过长占用系统大量资源，超时时间设置过长会导致用户等待时间过长。
其实根源还是在接口本身的性能上要有所提升，如果时间允许，还是需要提升这种批量操作的性能，从而提升用户体验。

6、阈值为线程数 、流控模式为直接、快速失败[的流控效果]

1）规则适用的业务特点

设置当前资源线程数量的阈值，当线程数达到阈值则后续线程会被直接拒绝，防止系统因线程过多导致资源耗尽。

2）适用场景

比如一些计算密集型的服务，像大数据分析任务处理接口，一定程度上要限制线程数来避免cpu出现资源过度占用的情况。
还有就是数据库的连接数，我们通常在配置连库信息时会设置，但是粒度不够细，可以通过限制请求库连接的线程数，来规避过多线程竞争数据库连接的情况，比如查库接口。

3）配置时要注意的事项

根据系统硬件资源和业务需求合理进行设置线程数阈值，避免过低影响系统正常并发处理能力，阈值过高那么流控规则就形同虚设了。

二）、配置注意事项总结

1、阈值评估

结合系统硬件资源（如cpu ,磁盘，内存，网络等）、资源重要度（业务的核心程度级别）以及历史流量峰值【大促期间和日常流量】，准确预估阈值，作为摸底性能测试基础数据，在此基础上，中小厂2到3倍，大厂10-20倍，留足余量，以此标准作压力测试期望指标，以系统实际性能指标，作为阈值依据。

若接口性能不达标：
对于核心流程资源接口，则要进行优化,不能一味去做限流处理。
对于非核心资源接口，则要根据当前项目周期紧急程度，评估是否作限流或降级处理。

2、规则要动态调整

随着时间的推移，业务在不停的迭代，用户体量以及系统的流量也会因此发生变化，以往的规则不足以恒久满足对系统性能的要求，所以要基于当前对系统性能的要求，对规则作动态调整。

3、监控与报警

结合Sentinel控制台或其他监控工具（如阿里云的arms监控），实时监控系统流量以及性能，cpu，磁盘，内存，网络等指标，合理设置报警的阈值，当流量接近或超过阈值时，及时通知相关人员。

4、规则持久化

使用Nacos、Zookeeper等配置中心存储流控规则，确保规则在服务重启后不会丢失，且可实现动态调整。

这个会在本栏目Sentinel文章的最后通过案例形式落地

5、测试及验证

在正式环境使用新的流控规则前，要在测试环境充分测试，验证规则的有效性以及合理性，避免影响正式环境
的业务。

看到这的小伙伴，你真的很棒！但是要坚持奥。

小结：

在保障核心业务稳定性的同时，最大化利用系统资源，满足不同业务场景的需求。实际应用中需结合压测数据、监控指标和业务特性动态调整规则。