在上文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