Sentinel的流控规则

Sentinel主要以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度来帮助您保护服务的稳定性，它的工作之一就是流量控制，所以我们要对流控规则进行了解与掌握。（这是我对流控规则的学习笔记的整理）

什么是流量控制？

• 流量控制，它用于调整网络包的发送数据。但是，从系统稳定性角度来说,任意时间到来的请求都是随机不可控的，而系统的处理能力是有限的。我们需要根据系统的处理能力对流量进行控制。
• 它的原理就是监控应用流量的 QPS 或并发线程数等指标，当达到指定的阈值时对流量进行控制，以避免被瞬时的流量高峰冲垮，从而保障应用的高可用性。
• 流量控制主要有两种统计类型，一种是统计并发线程数，另外一种则是统计 QPS。

Sentinel针对流控的名词解释：

• 资源名：唯一名称，默认请求路径
• 针对资源：sentinel可以针对调用者进行限流，填写微服务名，默认default(不区分来源)
• 阈值类型/单机阈值:
•        QPS(每秒钟的请求数量)：当调用该api的QPS达到阈值的时候，进行限流
•        线程数：当调用该api的线程数达到阈值的时候，进行限流
• 是否集群：不需要集群
• 流量模式：
•       直接：api达到限流条件时，直接限流
•       关联：当关联资源达到阈值时，就限流自己
•       链路：只记录指定链路上的流量（指定资源从入口资源进来的流量，如果达到阈值，就进行限流）【api级别的针对来源】
• 流控效果：
•       快速失败：直接失败，抛出异常
•       Warm Up（预热）: 根据codeFactor(冷加载因子，默认3)的值，从阈值/codeFactor,经过预热时长，才达到设置的QPS阈值
•       排队等待：匀速排队，让请求以匀速的速度通过，阈值类型必须设置为QPS，否则失效。

Sentinel的流控 

 1.对Sentinel-QPS-直接-快速失败（系统默认Blocked by Sentinel (flow limiting)）的尝试：

测试效果：

当我们快速点击访问 http://localhost:8401/testA ，每秒不超过一次，正常访问

 每秒访问超过一次，直接失败进行提示

2.对Sentinel-线程数-直接-快速失败（系统默认Blocked by Sentinel (flow limiting)）的尝试： 

测试效果：

根据Sentinel针对流控的名词解释： 线程数：当调用该api的线程数达到阈值的时候，进行限流

我们这里设置阈值为1，为了更方便我们进行观察，对TestA的代码进行修改（在浏览器上面进行访问时，要停留两秒）：

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

用同一个浏览器发送两个请求，其中一个就会直接失败

 3.对Sentinel-QPS-关联-快速失败（系统默认Blocked by Sentinel (flow limiting)）的尝试：

测试效果：

这里的意思就是当testB的QPS达到阈值1时，A就会挂掉，进行限流，即现实中当支付接口顶不住时达到阈值，与其相关联的下单接口就不用使用了，对其进行了限流

4. 对Sentinel-QPS-直接-Warm Up（系统默认Blocked by Sentinel (flow limiting)）的尝试：

 测试效果：

我对这个案例的理解：对于流控效果Warm up来说，现实中害怕流量明明为0或非常低，突然暴涨到极高的数字，从而可能把系统压垮。通过预热即“冷启动”，将流量缓慢增加，在一定的时间内恢复到设置的QPS阈值，即根据Warm Up预热公式，从（初始化阈值-->缓缓提升到正常的QPS阈值），最开始的初始化阈值是（QPS设置阈值/冷加载因子默认3）

 5.对Sentinel-QPS-直接-排队等待（系统默认为（Blocked by Sentinel (flow limiting)）的尝试：

测试效果：

• 无论有多少的并发请求，我设置了限流的规则是排队等待，就得一个一个处理，其他的在后面排队。
• 匀速排队，让请求以均匀的速度通过，阀值类型必须设成QPS,否则无效。
• 设置含义：/TestB每秒1次请求，超过的话就排队等待，等待的超时时间为20000毫秒,目的就是为了匀速处理请求，保证服务的均匀性，而不是一会处理大量的请求，一会有没有请求可处理。。

这里修改代码：

    @GetMapping("/testB")
    public String testB(){
        log.info("测试"+Thread.currentThread().getName()+"testB");
        return "-----testB";
    }

 打开Postman

 Sentinel流控规则的结语：

我这里主要展示了流量控制里面基于QPS/并发数的流量控制的QPS流量控制，这里回答一项思考就是当快速失败时展现出来的系统默认Blocked by Sentinel (flow limiting）报错信息，我们的后续处理是有一个fallback的兜底方法。