在上文Sentinel流量防卫兵中讲到了Sentinel入门以及流控规则一小部分，而Sentinel还有以下规则：
- 熔断降级规则
- 热点参数规则
- 系统规则
- 黑白名单规则
本文要讲的是流控规则
流量控制规则
原理
监控应用流量的 QPS 或并发线程数等指标，当达到指定的阈值时对流量进行控制，以避免被瞬时的流量高峰冲垮，从而保障应用的高可用性。
QPS限流
这里我们访问一下/foo/test接口，触发Sentinel控制台初始化，就可以看到在簇点链路中刷新出了该接口的资源
然后我们点击+流控添加流控规则，选择QPS，并且限流为2
在高级选项中还有流控模式和流控效果两个选择，默认为直接和快速失败，具体含义见下面解释
新增之后，在页面上快速点击几次，就会看到我们之前预设好的限流提示
流控效果
流控效果只针对于QPS的流量控制
快速失败
当QPS超过任意规则的阈值后，新的请求就会被立即拒绝，拒绝方式为抛出FlowException。这种方式适用于对系统处理能力确切已知的情况下，比如通过压测确定了系统的准确水位时。
案例见上
Warm Up
预热/冷启动方式，当系统长期处于低水位的情况下，当流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动"，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮。
在控制台中删除到刚刚测试的快速失败规则，新增一个Warm up效果的规则
这里我设置的qps阈值为10，预热3秒，等效于想要达到10qps，需要预热3秒。
这里测试需要用到一些压测工具，比如我用的是jmeter，毕竟在3秒内每秒连点10下我是做不到，认为自己行的可以自己试试。
以10qps进行压测之后，可以实时监控中看到这么一张效果图
在左边的线性图中可以看到通过的qps(绿线)是在匀速上升状态，直到3秒后达到10变为平稳状态，具体的数值可以从右边的表格看到。
排队等待
排队等待即为匀速排队，该方式会严格控制请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法。
同样的，在控制台新增规则
排队等待的阈值最高只能配1000哦，至于为什么小伙伴就自己想啦
以12qps进行压测，查看实时监控面板
qps一直保持在10, 规则生效了
流控模式
流控模式和调用关系有关，调用关系包括调用方、被调用方；一个方法又可能会调用其它方法，形成一个调用链路的层次关系。
直接
根据调用来源进行限流，默认为default，即针对所有的来源，这里面还可以配置自定义的来源。
1.自定义来源
自定义来源需要修改我们的配置代码，更改方式如下
private void addSpringMvcInterceptor(InterceptorRegistry registry) { SentinelWebMvcConfig config = new SentinelWebMvcConfig(); config.setBlockExceptionHandler(new MyBlockExceptionHandler()); // 区分请求方式 config.setHttpMethodSpecify(true); // 请求来源解析 config.setOriginParser(request -> request.getHeader("User-Agent")); registry.addInterceptor(new SentinelWebInterceptor(config)).addPathPatterns("/**"); }
在原来的配置中增加来源解析的配置，比如我这里就是获取请求头中的
User-Agent作为请求来源，你也可以根据自己的需求决定,比如获取客户端的ip
修改完毕后，重启服务，在控制台新增一个来源为test的规则
然后在请求上加上User-Agent的header，测试
这里如果把User-Agent换成其他的，则不会被限流
2. 其他
其他的意思除了指定的来源都会被限流，看到这里的就会让人有所疑问
- 控制台增加了
other来源的配置，之前的test来源就不会限流了吗？
其实它的意思是这样的：除了test来源的请求，其他来源的qps都不能超过其他这条配置，举个例子
test来源限流的qps为2，other来源限流的qps为1，那么此时如果是来自test2来源的请求，qps超过1则会提示已被限流，test来源的请求仍旧是超过2之后才会提示被限流。
在控制台增加一条其他来源的配置
设置User-Agent为test2进行测试
可以看到，我这里只请求了1次就被限流了
关联
关联这个模式指的是如果一个资源被两个接口所访问，那么在一个接口超过qps阈值时，可以对另一个接口进行限流。
举个例子来说，FooService同时被A接口和B接口所访问，由于FooService总体能够接受的qps是恒定的，如果A接口qps过高，那么B接口的就会受到影响，如果我们想要B接口优先，此时我们就可以配置一条当B接口超过qps阈值时，就把A接口限流。
听起来是不是特别别扭😂， 如果这俩接口有思考能力，我自行脑补出了以下场景：
B接口：我超速了，警察，快把A接口逮捕了，它影响到我超速了。
A接口：？？？
在代码里面新增一个foo/test2接口，重启服务
在控制台增加配置
以上配置表示：当/foo/test接口达到qps为10的阈值时，就对/foo/test2进行限流
测试方式：使用jmeter对/foo/test接口进行压测，然后再请求/foo/test2看看是否被限流了
假装已经开始对/foo/test接口进行压测了，请求/foo/test2
可以看到，这里随便请求了一下就返回了限流提示
链路
链路模式和关联模式有点像，但是不再是我影响你这种关系了。而指的是如果一个资源被两个接口所访问，那么我们可以指定只对其中某个接口进行限流。
还是那个例子，FooService同时被A接口和B接口所访问，此时如果想对UserService作qps为10的限流，之前的方式就是直接配置一个FooServiceqps阈值为10的规则，这样A,B两个接口都会被限制访问，但是如果我只想对A接口的访问进行限流，B接口的不管，那么就需要使用链路模式了。
但是但是，在目前最新的版本(1.8.2)里，这个规则不生效！
并发线程数
概念
不同于qps，并发线程数限定的是某个资源的线程数并发上线，用于保护业务线程池不被慢调用耗尽。
前段时间我的同事就刚好遇上了这样的问题：
某个接口因为一个bug，线程被阻塞了， 导致所有打到这个接口的请求全部陷入阻塞状态。我们知道tomcat的总线程数是有限的，出现这个问题之后的一小会，这个服务的所有线程都阻塞在这个接口上了，tomcat线程池直接耗尽，所有接口502
如果当时该接口的并发数存在一个阈值，那这个bug所涉及的范围就可以控制在很小的范围内了。
演示
新增一个接口，用于模拟线程并发情况
public String test3() throws InterruptedException { // 线程停顿1秒， TimeUnit.SECONDS.sleep(1); return "ok"; }
重启服务，访问/foo/test3接口触发初始化
在控制台添加配置
开启jmeter进行压测该接口，然后在其他地方访问一下(为了好观察)
规则生效了。
其他的流控模式与qps方式相同，这里就不演示了
小结
本文介绍了Sentinel的流控规则，其中根据场景分为QPS限流以及并发线程数限流。
这两个限流策略的共同点为：可以对来源进行针对限流，支持直接,关联,链路三种流控模式。
而QPS限流还包含了三种流控效果: 快速失败、预热、排队等待。
至于是否集群那个选项小伙伴就当没看到哈，我搞不定这个，我认怂
实在想研究，官方文档在此：https://github.com/alibaba/Sentinel/wiki/%E9%9B%86%E7%BE%A4%E6%B5%81%E6%8E%A7
本文案例代码：https://gitee.com/lzj960515/my-micro-service-demo
