一．**** 阈值类型和流控模式
界面配置专业词汇概述：
1.****阈值类型 QPS、流控模式 直接
测试代码service
测试代码限流代码(参数和返回类型必须和@SentinelResource注解的方法一样，最后一个参数为BlockException)
控制层代码
每秒允许请求数为 5
请求并进行测试：
测试需要讲究快速点击、缓慢点击
· 缓慢点击· JMeter多线程测试快速点击
·表示1秒内，查询5次请求OK； 如果请求在1秒内的次数高于5次，则进入快速失败流程，进入熔断限制函数中！
2.****阈值类型 线程数、流控模式 直接
Service
Controller
单个请求：
了解 QPS 和线程数这两种方式的区别：
Jmeter10个线程请求测试：
限流了
3.****阈值类型 QPS、流控模式 关联
此次的配置采取如下方式：
当关联的资源达到限流条件时，开启限流 配置请求 /test2 限流QPS，关联 /test1文档解释现象：
/test1 与 /test2 有关联关系。 若 /test2 达到阈值时，会对 /test1 进行限流！
实用背景：
下单和支付接口进行关联。 如若支付接口达到阈值，就限定下单接口少产生支付接口，缓解压力！如何进行测试呢？
1、正常请求 /test1，无关乎快速还是缓慢，都会是正常返回信息。 2、循环不断请求/test2，触发该接口的限流操作。 3、再次请求/test1，查看请求回执状态信息。
正常请求/test1：
http://localhost:8500/test1 无论快慢，都是返回下列信息！
使用postman、jmeter等工具，迭代请求/test2，触发限流后，再次请求/test1查看回执状态信息：
运行 postman，浏览器访问：http://localhost:8500/test1
现象：
当/test2触发了限流，此时的/test1请求将会受到影响！ 当/test2限流结束，/test1才能继续请求得到回执！
4.****QPS、链路
链路：当从某个接口过来的资源达到限流条件时，开启限流。
链路流控是针对上级接口！
二．****Sentinel 流控效果
此处的效果测试，均采用 阈值类型：QPS、流控模式：直接。
1.****直接
直接失败，抛出异常，不做任何额外处理，是最简单的方式。
2.****Warm Up
从开始阈值，到最大QPS阈值会有一个缓冲阶段， 一开始的阈值是最大QPS阈值的1/3，然后缓慢增长，直到最大阈值，适用于突然增大的流量转化为缓步增长。 避免突然大流量造成服务器的宕机！
阈值最初为10； 最初的处理请求数最大为：10/3=3； 在5s时间内，由3缓慢升为10。
突然出现大量请求，不会直接进行实际处理，会将请求预热后在做处理！
3.****排队等待
让请求以均匀的速率通过，单机阈值为每秒通过的请求数，其余的排队等待； 其次，还可以设置一个排队等待的超时时间，若请求在超时时间内还未被处理，则会被丢弃。
达到的目的： 匀速处理多个请求，而不是一开始超过阈值的请求直接失败！
观察发现： 每秒钟限定处理一个请求数。 但是jmeter每秒钟发送2个请求。 设置了延迟等待 500ms后，只有少数请求会进入降级！
三．****Sentinel熔断降级
· 平均响应时间 (DEGRADE_GRADE_RT)：当 1s 内持续进入 N 个请求，对应时刻的平均响应时间（秒级）均超过阈值（count，以 ms 为单位），那么在接下的时间窗口（DegradeRule 中的timeWindow，以 s 为单位）之内，对这个方法的调用都会自动地熔断（抛出 DegradeException）。注意Sentinel 默认统计的 RT 上限是 4900 ms，超出此阈值的都会算作 4900 ms，若需要变更此上限可以通过启动配置项-Dcsp.sentinel.statistic.max.rt=xxx 来配置。
· 异常比例 (DEGRADE_GRADE_EXCEPTION_RATIO)：当资源的每秒请求量 >= N（可配置），并且每秒异常总数占通过量的比值超过阈值（DegradeRule 中的 count）之后，资源进入降级状态，即在接下的时间窗口（DegradeRule 中的 timeWindow，以 s 为单位）之内，对这个方法的调用都会自动地返回。异常比率的阈值范围是 [0.0, 1.0]，代表 0% - 100%。
· 异常数 (DEGRADE_GRADE_EXCEPTION_COUNT)：当资源近 1 分钟的异常数目超过阈值之后会进行熔断。注意由于统计时间窗口是分钟级别的，若 timeWindow 小于 60s，则结束熔断状态后仍可能再进入熔断状态。
1、RT 平均响应时间
1、如果请求的平均响应数超过阈值(ms)，则会进入准降级状态。 2、如果接下来1s内持续进入5个请求，他们的RT都持续超过了这个阈值，那么在接下来的时间窗口(s)内，就会对这个服务进行降级。 3、RT默认最大为4900ms，如果需要更大，可以通过 -Dcsp.sentinel.statistic.max.rt=xxx 进行配置。
配置案例： java代码逻辑为：
请求测试：
不会出现熔断保护。 2、异常请求： http://localhost:8500/jiangji?name=1
保护时间过后，在请求正常流程：
[总结]
1、配置熔断保护的接口，如果不出现超时情况时，不会触发熔断保护降级。 2、当设定RT为400ms后，请求异常流程，1s内平均请求响应都超时并达到对应的数目(测试显示5个)，会触发熔断保护，并保护10s(这个时间是时间窗口的配置)。 3、熔断保护期间内，正常请求也会被熔断、降级。 4、10s后，熔断结束，会重新对请求响应时间进行统计判断。
2、异常比例数
每秒的异常总数，占通过量的比值超过配置的值之后，触发熔断降级。 时间窗口和之前一样，属于熔断保护时间。 占的比值数范围为：[0.0,1.0]；
代码案例：
暂时未配置时，当请求数每次达到 a % 2== 0时，就会产生异常：
由于 a % 2 == 0触发异常，也就是说异常比例为 1/2。只需要配置的数小于 1/2即可。
请求测试：
正常缓慢请求时，依然和之前一致，出现报错信息。 当请求异常比例大于等于配置数时，出现熔断降级。
3、异常数
资源 1分钟 内的异常总数超过限定的阈值，触发熔断降级！
设定异常数为3，表示一分钟请求的异常出现了3个及以上，触发熔断降级！
[注意]此处有坑！
由于异常数是按照分钟统计的个数，时间窗口中的设置也必须要大于60s。 不然会出现：结束熔断保护后仍可能继续熔断保护(不会释放！)
请求测试：
当请求出现异常的次数达到设定的值时，立马出现熔断降级现象。四****、Sentinel热点规则
热点参数流控规则。
何为热点：
热点即经常访问的数据。
热点限流的思想是什么？
假设某一时间段内的某个用户频繁的去访问，就可以采取热点规则方式，对其进行限流操作。
1、初级配置和测试
案例测试：
当不配置任何规则时，此时的回执信息为：
当请求地址携带p1参数，且每秒钟的请求数高于配置的1次时，触发降级。
请求测试：
1、不携带参数，快速点击
2、携带参数，但不携带p1，快速点击
3、携带p1参数，缓慢点击
4、携带p1参数，快速点击
高级配置
针对个别用户频繁访问时，采取了限流操作(按照参数接受类型，但不是具体的数值)。 但是，针对管理员频繁的访问查看或测试数据时，此时不应限流。
配置项：
达到的目的，当p1为520时，限流量放大！
请求测试：
1、缓慢请求，p1非特定值4、快速请求，p1为特定值（每秒请求大于3才触发限流）
Sentinel系统自适应限流
之前的配置操作，采取的是针对单个请求地址、请求别名进行配置的限流操作，sentinel同时也提供了一种很潮流的方式实现配置操作—系统自适应限流。
何为系统自适应限流？
Sentinel 系统自适应限流从整体维度对应用入口流量进行控制，结合应用的 Load、CPU 使用率、总体平均 RT、入口 QPS和并发线程数等几个维度的监控指标，通过自适应的流控策略，让系统的入口流量和系统的负载达到一个平衡，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。
《系统自适应限流》
文档中，对系统自适应限流有如下几种配置：阈值类型的含义如下所示：
· Load 自适应(****仅支持Linux/Unix-like****) 系统的 load1 作为启发指标，进行自适应系统保护。当系统 load1 超过设定的启发值，且系统当前的并发线程数超过估算的系统容量时才会触发系统保护（BBR 阶段）。系统容量由系统的 maxQps * minRt 估算得出。设定参考值一般是 CPU cores * 2.5。(系统核心数*2.5)
· CPU usage（****1.5.0+ 版本****） 当系统 CPU 使用率超过阈值即触发系统保护（取值范围 0.0-1.0），比较灵敏。
· 平均 RT 当单台机器上所有入口流量的平均 RT 达到阈值即触发系统保护，单位是毫秒。
· 并发线程数 当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护。
· 入口 QPS 当单台机器上所有入口流量的 QPS 达到阈值即触发系统保护。
配置案例： 配置入口QPS
只配置 QPS 项，其他流控模式未配置。