【SpringCloud Alibaba】Sentinel流控规则

概念

流控规则

直接（默认）

QPS+快速失败

线程数+直接控制

QPS+Warming up

QPS+排队等待

关联

链路

---

具体启动Sentinel的步骤可以参考我的上一篇文章。

概念

资源名：唯一名称，默认请求路径

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

阅值类型单机阅值：
        QPS(每秒钟的请求数量)：当调用该api的QPS达到值的时候，进行限流
        线程数：当调用该api的线程数达到阔值的时候，进行限流

是否集群：不需要集群

流控模式：
        直接：api达到限流条件时，直接限流
        关联：当关联的资源达到闻值时，就限流自己
        链路：只记录指定链路上的流量(指定资源从入口资源进来的流量，如果达到阔值，就进行限流)[api级别的针对来源]
流控效果：
        快速失败：直接失败，抛异常
        Warm Up(预热)：根据codeFactor (冷加载因子，默认3) 的值，从闻值/codeFactor，经过预热时长，才达到设置的QPS闽值
        排队等待：匀速排队，让请求以匀速的速度通过，阔值类型必须设置为QPS，否则无效

流控规则

直接（默认）

控制层方法如下：

@RestController
public class SentinelController {

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

    @GetMapping("/testB")
    public String testB(){
        return "Sentinel testB run";
    }
}

QPS+快速失败

通过地址栏输入：localhost:8401/testA

测试发现当每秒刷新页面的次数大于1则会弹出以下页面（表示限流），否则正常

线程数+直接控制

        而直接控制的线程数设置为1表示如果超过一个页面访问此连接那就会限流否则正常。这里就不再对线程数做测试了

QPS+Warming up

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

举例：当预热时长=8，QPS单机阈值=3

• 当并发请求到达的时候，实际的单机阈值是：QPS单机阈值配置 / coldFactoer= 3 / 3 =1,也就是每秒钟只能一个请求访问成功。
• 预热时长为8秒，实际的单机阈值在8秒钟内逐步由1 -> 2 -> 3,最终等于QPS单机阈值配置。
• 这里有一个注意点是QPS单机阈值一定要大于或等于3否则会一直请求不成功 

QPS+排队等待

        排队等待方式会严格的控制请求通过的间隔时间，就是让请求匀速的通过，对应的是漏桶算法。

言简意赅：QPS对应每秒处理的线程为1，超时时间表示超过10s则不接受其他线程的请求。也就是说将超时时间(ms) / 单机阈值(s/个) = 线程通过数。

关联

        使用了testA关联testB那么当二者其一越界了即二者其一或者触犯了阈值规则，那么规则的时长内即QPS内testA是无法访问的，换句通俗易懂的就是：其中一个犯错，testA就得扛锅。但要注意的是不是永久失效，只是阈值内失效。

链路

        与关联相反。两者之一犯错，那么就是入口资源背锅。

 关联与链路的区别

关联：

配置: “查询订单” 关联 “下单” 接口, 当"下单"到达阈值, 限流"查询订单"接口

链路：
配置: “查询订单”为入口时, 当"查询订单"到达阈值时, 限流"查询订单"