关于springcloud:Sentinel之流控规则

在上文 Sentinel 流量防守兵中讲到了 Sentinel 入门以及流控规定一小部分，而 Sentinel 还有以下规定：

熔断降级规定
热点参数规定
零碎规定
黑白名单规定

本文要讲的是流控规定

监控利用流量的 QPS 或并发线程数等指标，当达到指定的阈值时对流量进行管制，以防止被刹时的流量顶峰冲垮，从而保障利用的高可用性。

这里咱们拜访一下 /foo/test 接口，触发 Sentinel 控制台初始化，就能够看到在 簇点链路 中刷新出了该接口的资源

而后咱们点击 + 流控 增加流控规定，抉择 QPS，并且限流为 2

在高级选项中还有流控模式和流控成果两个抉择，默认为间接和疾速失败，具体含意见上面解释

新增之后，在页面上疾速点击几次，就会看到咱们之前预设好的限流提醒

流控成果只针对于 QPS 的流量管制

当 QPS 超过任意规定的阈值后，新的申请就会被立刻回绝，回绝形式为抛出FlowException。这种形式实用于对系统解决能力确切已知的状况下，比方通过压测确定了零碎的精确水位时。

案例见上

预热 / 冷启动形式，当零碎长期处于低水位的状况下，当流量忽然减少时，间接把零碎拉升到高水位可能霎时把零碎压垮。通过 ” 冷启动 ”，让通过的流量迟缓减少，在肯定工夫内逐步减少到阈值下限，给冷零碎一个预热的工夫，防止冷零碎被压垮。

在控制台中删除到刚刚测试的 疾速失败 规定，新增一个 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

关于springcloud:Sentinel之流控规则

流量管制规定

原理

QPS 限流

流控成果

疾速失败

Warm Up

排队期待

流控模式

间接

1. 自定义起源

2. 其余

关联

链路

并发线程数

概念

演示

小结