顾名思义：默认的流量控制方式，当QPS超过任意规则的阈值后，新的请求就会被立即拒绝，拒绝方式为抛出FlowException。上面的几个例子都是配置了直接拒绝这个模式，这里不再详细介绍。
关联典型的使用场景：一个是支付接口，一个是下单接口，此时一旦支付接口达到了阈值，那么订单接口就应该被限流，不然这边还在下单，消费者等待或者直接被拒绝支付将会极大的影响用户体验。
简而言之：A关联B，一旦B达到阈值，则A被限流
演示一下效果，创建以下两个接口：
@RestController @RequestMapping("/sentinel") public class FlowLimitController { /** * 下单接口 * @return */ @GetMapping("/order") public String order() { return "下单成功.........."; } /** * 支付接口 * @return */ @GetMapping("/pay") public String pay() { return "支付成功.........."; } }此时的流控规则配置如下图：
注意：关联之后，这里设置的限流规则是对被关联资源，也就是/sentinel/pay这个资源，但是真正被限流则是/sentinel/order。
如何演示效果呢？很简单，只需要不断的请求/sentinel/pay达到阈值，然后在请求/sentinel/order。
利用POSTMAN不断向/sentinel/pay发出请求，然后浏览器请求/sentinel/order，结果如下图：
可以看到订单接口被限流了.............
3、两种统计类型流控分为两种统计类型，分别是QPS，并发线程数，很多人不太明白这两种统计类型有什么区别？
举个栗子：陈某带了一个亿去银行存钱，但是银行大门保安要查健康码，每秒最多只能同时进入4个人，并且银行中只有两个工作人员工作，如下图：
此时的QPS含义：从保安到银行这一段，即是保安放行进入银行的人数。
此时并发线程数的含义：银行只有两个工作人员在工作，那么最多只能同时处理两个任务，这里并发线程数的阈值就是2。
8、降级规则如何配置？熔断降级在日常生活中也是比较常见的，场景如下：
股票市场的熔断，当价格触发到了熔点之后，会暂停交易一段时间，或者交易可以继续进行，但是报价会限制在一定的范围。
电压过高导致保险丝触发熔断保护
在大型的分布式系统中，一个请求的依赖如下图：
如果这个时候，某个服务出现一些异常，比如：
服务提供者不可用(硬件故障、程序bug、网络故障、用户请求量较大)
重试导致的流量过大
服务调用者使用同步调用，产生大量的等待线程占用系统资源，一旦线程资源被耗尽，调用者提供的服务也会变成不可用状态
那么将会导致整个服务不可用，用古话来讲就是：千里之堤毁于蚁穴。
所谓编程源于生活，架构师们根据生活的经验设计出了服务的熔断降级策略，很好的解决了这类问题。
熔断降级规则对应sentinel控制台的降级规则这一栏，如下图：
熔断降级涉及到的几个属性如下表：
源码中对应得类为：com.alibaba.csp.sentinel.slots.block.degrade.DegradeRule。
三种熔断策略Sentinel 提供以下几种熔断策略：
平均响应时间 (DEGRADE_GRADE_RT)：当 1s 内持续进入 5 个请求，对应时刻的平均响应时间（秒级）均超过阈值（count，以 ms 为单位），那么在接下的时间窗口（DegradeRule 中的 timeWindow，以 s 为单位）之内，对这个方法的调用都会自动地熔断（抛出 DegradeException）。注意 Sentinel 默认统计的 RT 上限是 4900 ms，超出此阈值的都会算作 4900 ms，若需要变更此上限可以通过启动配置项 -Dcsp.sentinel.statistic.max.rt=xxx 来配置。