Sentinel流控规则实现限流保护详解

具体启动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就得扛锅。但要注意的是不是永久失效，只是阈值内失效。

链路

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

关联与链路的区别

关联：

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

链路：

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

到此这篇关于Sentinel流控规则实现限流保护流程详解的文章就介绍到这了,更多相关Sentinel流控规则内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论