目录

springcloudAlibaba_sentinel 热点参数、系统规则

概述

官方说明

何为热点?热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最高的 Top K 数据,并对其访问进行限制。比如:

  • 商品 ID 为参数,统计一段时间内最常购买的商品 ID 并进行限制
  • 用户 ID 为参数,针对一段时间内频繁访问的用户 ID 进行限制

热点参数限流会统计传入参数中的热点参数,并根据配置的限流阈值与模式,对包含热点参数的资源调用进行限流。热点参数限流可以看做是一种特殊的流量控制,仅对包含热点参数的资源调用生效。

http://img.cana.space/picStore/20201115163430.png

Sentinel 利用 LRU 策略统计最近最常访问的热点参数,结合令牌桶算法来进行参数级别的流控。热点参数限流支持集群模式。

从@HystrixCommand到@SentinelResource

兜底方法,分为系统默认和客户自定义两种,之前的case,限流出问题后,都是用sentinel系统默认的提示:“Blocked by Sentinel (flow limiting)”,能不能像HystrixCommand一样,某个方法出问题了,就找到对应的兜底降级方法。可以使用注解@SentinelResource。

热点参数规则说明

演示使用

依赖

要使用热点参数限流功能,需要引入以下依赖:

1
2
3
4
5
<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-parameter-flow-control</artifactId>
    <version>x.y.z</version>
</dependency>

已经包含在spring-cloud-starter-alibaba-sentinel依赖当中。

代码

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
@GetMapping("/testHotParam")
        // value不写默认访问路径去掉/
        @SentinelResource(value = "srTestHotParam", blockHandler = "testBlockHandler")
        public String testHotParam(
                @RequestParam(value = "p1", required = false) String p1,
                @RequestParam(value = "p1", required = false) String p2
        ) {
            /**
             * blockHandler处理的是控制台配置的违规情况,有blockHandler方法配置的兜底处理
             * 如果是程序异常,则应由fallback进行降级处理,或者程序自己处理
             */
//            int i = 10/0;
            return "testHotParam";
        }

        // 注意方法权限修饰符也要是public
        public String testBlockHandler(String p1, String p2, BlockException blockException) {
            return "热点参数, blockException";
        }

配置热点规则

http://img.cana.space/picStore/20201115165410.png

验证

访问 http://localhost:8401/testHotParam?p1=1,狂刷,会返回我们自己定义的内容

http://img.cana.space/picStore/20201115170126.png

配置热点规则例外

http://img.cana.space/picStore/20201115171332.png

注意将上图int修改成string, 和代码中参数类型保持一致,否则不生效。

增加一个例外,当p1等于5时,限流阈值等于200,狂刷http://localhost:8401/testHotParam?p1=5,此时正常访问

系统自适应限流

Sentinel 系统自适应限流从整体维度对应用入口流量进行控制,结合应用的 Load、CPU 使用率、总体平均 RT、入口 QPS 和并发线程数等几个维度的监控指标,通过自适应的流控策略,让系统的入口流量和系统的负载达到一个平衡,让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。

http://img.cana.space/picStore/20201115172620.png

系统规则

系统保护规则是从应用级别的入口流量进行控制,从单台机器的 load、CPU 使用率、平均 RT、入口 QPS 和并发线程数等几个维度监控应用指标,让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。

系统保护规则是应用整体维度的,而不是资源维度的,并且仅对入口流量生效。入口流量指的是进入应用的流量(EntryType.IN),比如 Web 服务或 Dubbo 服务端接收的请求,都属于入口流量。

系统规则支持以下的模式:

  • Load 自适应(仅对 Linux/Unix-like 机器生效):系统的 load1 作为启发指标,进行自适应系统保护。当系统 load1 超过设定的启发值,且系统当前的并发线程数超过估算的系统容量时才会触发系统保护(BBR 阶段)。系统容量由系统的 maxQps * minRt 估算得出。设定参考值一般是 CPU cores * 2.5
  • CPU usage(1.5.0+ 版本):当系统 CPU 使用率超过阈值即触发系统保护(取值范围 0.0-1.0),比较灵敏。
  • 平均 RT:当单台机器上所有入口流量的平均 RT 达到阈值即触发系统保护,单位是毫秒。
  • 并发线程数:当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护。
  • 入口 QPS:当单台机器上所有入口流量的 QPS 达到阈值即触发系统保护。

自适应限流原理

先用经典图来镇楼:

http://img.cana.space/picStore/20201115172840.png

我们把系统处理请求的过程想象为一个水管,到来的请求是往这个水管灌水,当系统处理顺畅的时候,请求不需要排队,直接从水管中穿过,这个请求的RT是最短的;反之,当请求堆积的时候,那么处理请求的时间则会变为:排队时间 + 最短处理时间。

  • 推论一: 如果我们能够保证水管里的水量,能够让水顺畅的流动,则不会增加排队的请求;也就是说,这个时候的系统负载不会进一步恶化。

我们用 T 来表示(水管内部的水量),用RT来表示请求的处理时间,用P来表示进来的请求数,那么一个请求从进入水管道到从水管出来,这个水管会存在 P * RT 个请求。换一句话来说,当 T ≈ QPS * Avg(RT) 的时候,我们可以认为系统的处理能力和允许进入的请求个数达到了平衡,系统的负载不会进一步恶化。

接下来的问题是,水管的水位是可以达到了一个平衡点,但是这个平衡点只能保证水管的水位不再继续增高,但是还面临一个问题,就是在达到平衡点之前,这个水管里已经堆积了多少水。如果之前水管的水已经在一个量级了,那么这个时候系统允许通过的水量可能只能缓慢通过,RT会大,之前堆积在水管里的水会滞留;反之,如果之前的水管水位偏低,那么又会浪费了系统的处理能力。

  • 推论二: 当保持入口的流量是水管出来的流量的最大的值的时候,可以最大利用水管的处理能力。

然而,和 TCP BBR 的不一样的地方在于,还需要用一个系统负载的值(load1)来激发这套机制启动。

注:这种系统自适应算法对于低 load 的请求,它的效果是一个“兜底”的角色。对于不是应用本身造成的 load 高的情况(如其它进程导致的不稳定的情况),效果不明显。