一、阀值类型
1、QPS：
上一章已经测试了QPS，每秒允许请求次数。
2、并发线程数：
是处理该资源请求的并发线程数量。
由于测试代码后端的逻辑太简单就一句，所有执行时间消耗特别快，为了测试效果需要增加每秒请求次数，设置为1000，使用Jmeter测试工具（上章节有讲到），如下：
结果：
请求通过了326次，拒绝了674次。
二·、流控模式
1、快速失败
可以说是不做额外处理，请求达到单机阀值时，直接抛出异常。
2、Warm Up
warm 预热，指的是前几面需要预热几秒，在预热时间内，默认阀值是3，预热时间后才会执行你设置的阀值，比如如下：
单机阀值设置为10，预热时长是3，表示，前3秒，只允许每秒3次请求通过，3秒之后则允许每秒10次请求通过，结果如下：
为了实现效果，我设置为一秒执行15个请求，一直循环执行
又结果可以看出，前面32,33,34秒都是4次左右/秒通过请求，然后稳定于10次左右/秒通过请求。实现了预热的效果。
3、排队等待
设置超时时间，指定阀值，若每秒内的请求数量达到阀值，则超出阀值得请求进入等待队列，等待前面指定阀值得请求执行完，若等待队列内的请求在超时时间之后仍然没有被消费掉则直接从队列内消失。测试如下：
如此设置，若QPS阀值为10，若是直接失败处理的话，会导致5个请求直接返回异常，若使用排队等待的话，只要超时时间不超过指定时间就不会进行失败处理，如下：
15条请求全部被处理了，超时处理的4条在45秒时也进行了处理，而不是在44秒是拒绝了4条。
三、流控效果
1、直接
当达到设置的流控条件时就直接进行流控处理。
2、关联
当关联的资源达到流控条件时就对当前资源进行流控处理。
为了方便测试，新增一个test2接口进行资源关联，如下：
sentinel如下设置：
在test2设置流控规则，若对test1接口的请求达到阀值10，则让对test2接口的请求快速失败。
相比前面，这次在jmeter的计划工程里新增一个调用test2接口的http请求任务。
发起测试，每秒15次请求。
由结果可以看到，的确test1正常通过了15次的请求，而test2拒绝了5次，大概就是在12秒时test1已经通过了14次，超过了设置的阀值了，所以test2就直接拒绝了之后的请求，13秒test2又通过了一次应该是存在误差，也测试了上万条的请求时，的确test2之后不会再通过请求，全部会拒绝。
3、链路
表示，只有通过某某接口访问某某资源时，才会触发流控效果，例如将程序中X方法定义成sentinel的资源，而A、B两个接口都调用了X方法，则可以通过设置链路的方法只针对某一个接口进行对该资源的流控，此处需要使用sentinel的注解SentinelResource来定义sentinel可以识别的资源。
为了方便测试该方式，新增一个类，如下：
加上component注解，交由spring管理，加上sentinelresource注解，让sentinel可以认识该资源，并给他取一个名字，修改controller，调用该资源，如下：
在sentinel给资源ceshi666设置流控规则，如下：
意味着若通过test1接口访问的ceshi666资源若每秒请求次数超过阀值10就会快速失败，为了测试结果，还是同时请求test1和test2接口进行比较，如下：
深坑：当然：只这样还不行，版本坑又来了，高版本的sentinel依赖不能直接使用这个东西，还需要修改一个配置，如下：
前面我给自己埋了一个坑，现在补上，sentinel的依赖引错了，现在改正，改正之后如下：
注意！注意！注意！一定要是2.1.1版本，不然又要错。
还要再引入一个新的依赖：
缺一不可，整了很久。
最后再新增一个配置类，不然还是用不起！！！
重启服务，重新配置资源ceshi666的流控规则，现在开始测试：
结果如下：
test1请求的ceshi666被拒绝了4次，test2请求的ceshi666全部通过，存在误差，但是起码效果出来了。再进行转换，流控规则入口设置为test2，如下：
结果：
test2接口调用的ceshi666被拒绝了3次，控流成功。
下一章将学习熔断处理。
