上述配置的具体含义：当OrderQuery这个资源中的第0个参数QPS超过1秒1次将会被限流。这里参数索引是从0开始，第0个就是对应接口中的p1这个参数。
第一个测试：浏览器直接访问：:9009/sentinel/provider/order/query?p1=22&p2=1222，连续点击将会看到这个接口被熔断降级了，如下图：
这也正是验证了上述的热点参数限流配置。
第二个测试：浏览器输入：:9009/sentinel/provider/order/query?p2=1222，连续点击将会看到这个接口并没有被熔断降级，如下图：
注意：对于热点参数限流，只有包含指定索引的参数请求才会被限流，否则不影响。
此时产品说：ID为100的这个产品点击量太少了，你们赶紧调整下这个商品的限流规则。这个时候该怎么办呢？
别着急，sentinel显然考虑到了这一点，提供了参数例外项这项配置，针对产品需求配置如下：
从上图配置中，我们将参数值p1这个参数值等于100的时候，限流阈值设置成了100，也就是说p1=100这个请求QPS放宽到1秒请求100次以上才会被限流。
验证：浏览器输入地址：:9009/sentinel/provider/order/query?p1=100，无论点击多么快，都没有被熔断降级，显然是配置生效了，如下图：
以上源码在sentinel-openfeign-provider9009这个模块中，文末有源码获取方式。
10、系统自适应如何限流？前面热点参数、普通流量限流都是针对的某个接口，这里系统自适应限流针对是整个系统的入口流量，从单台机器的 load、CPU 使用率、平均 RT、入口 QPS 和并发线程数等几个维度监控应用指标，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。
sentinel控制台对应如下图：
阈值类型有五种，分别如下：
Load 自适应（仅对 Linux/Unix-like 机器生效）：系统的 load1 作为启发指标，进行自适应系统保护。当系统 load1 超过设定的启发值，且系统当前的并发线程数超过估算的系统容量时才会触发系统保护（BBR 阶段）。系统容量由系统的 maxQps * minRt 估算得出。设定参考值一般是 CPU cores * 2.5。
CPU usage（1.5.0+ 版本）：当系统 CPU 使用率超过阈值即触发系统保护（取值范围 0.0-1.0），比较灵敏。
平均 RT：当单台机器上所有入口流量的平均 RT 达到阈值即触发系统保护，单位是毫秒。
并发线程数：当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护。
入口 QPS：当单台机器上所有入口流量的 QPS 达到阈值即触发系统保护。
官方文档：https://github.com/alibaba/Sentinel/wiki/系统自适应限流
系统规则的配置比较简单，这里以入口QPS为例进行演示，为了演示真实情况，清掉所有的限流规则，添加系统规则，如下图：
这个QPS系统规则一配置，该微服务中的所有接口都将会被这个规则限制，比如访问：:9009/sentinel/provider/pay，连续点击，如下图：
可以看到已经被限流了，不仅是这个接口，所有接口都会生效。
注意：系统规则中的入口QPS这个规则不建议配置，一旦配置上了可能导致整个服务不可用。
11、如何自定义限流返回的异常信息？在前面的例子中，无论是熔断降级还是被限流返回的异常信息都是Blocked by Sentinel (flow limiting)，这个是Sentinel默认的异常信息。
很显然默认的异常信息并不能满足我们的业务需求，因此我们需要根据前后端规则制定自己的异常返回信息。
这里将会用到一个注解@SentinelResource，这个在上文也是提到过，这个注解中有两个关于限流兜底方法的属性，如下：