sentinel流控模式及效果

首先我们为sentinel准备好两个资源 ，分别是hello和sentinel

流控

qps即Query Per Second，每秒的请求数

线程数顾名思义就是对该处理该资源时创建的线程数

default代表所有来源

 单机阈值，超出阈值的请求将会被sentinel流控，如下

 高级选项

流控模式：

1. 直接

        即该规则对当前资源（接口生效）

2.关联（此处为反向关联）

如上，假设我针对/hello资源设置qps阈值为1的流控规则，其关联的资源为sentinel

如果按照传统思维我们可能以为以下的设置是指：  当/hello的qps超过1时，将会对/sentinel进行限流

但这里的关联实际为反向关联，即当/sentinel的qps超过1，sentinel将会对/hello进行限流，当我以超过阈值的qps请求/sentinel资源时，我们去访问/hello资源，效果如下

 3.链路

首先需要注意

Sentinel默认会将Controller方法做context整合，导致链路模式的流控失效，需要修改application.yml，添加配置关闭context的整合

spring.cloud.sentinel.web-context-unify=false

示例：新建一个service，其中有一个方法testService()，用@SentinelResource注解将其标注为sentinel的资源，否则sentinel默认只会将controller中的接口作为资源,

再hello和sentinel中均调用此方法

service

 controller

在sentinel dashboard中查看簇点链路

 此时我们对于testService资源来说，调用它的链路有两条，分别是

/hello -> testService

/sentinel -> testService

我们新增如下的流控规则，即代表如果从/hello链路调用testService将会受到sentinel的qps阈值为1的流控规则，而其他链路(如/sentinel)链路调用则不受影响 

流控效果(流控效果均只针对于qps模式)

 1.快速失败

即由sentinel直接返回失败结果

 2. Warm up（冷启动，预热）

即让请求的qps阈值根据设定的时长缓慢增加至最大的阈值，如下图即让qps阈值从5秒内缓慢增加至10（初始值由sentinel决定）

3.排队等待

顾名思义，让进来的请求排队依次通过，但不可能让请求一直排队，因此我们可以设置请求的超时时间，如果超过等待时间则直接失败。