共计 3274 个字符，预计需要花费 9 分钟才能阅读完成。
在上文 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/Se…
本文案例代码：https://gitee.com/lzj960515/m…
追更，想要理解更多精彩内容，欢送关注公众号：程序员阿鉴
集体博客空间：https://zijiancode.cn
