SpringCloud Alibaba - Sentinel 限流规则（案例 + JMeter 测试分析）

一、Sentinel 限流规则

1.1、簇点链路

1.2、流控模式

1.2.1、直接流控模式

1.2.2、关联流控模式

a）在 OrderController 中新建两个端点.

b）在 Sentinel 控制台中对订单查询端点进行流控

c）使用 JMeter 进行测试

d）分析结果

1.2.3、链路流控模式

a）在 OrderService 中添加 queryGoods 方法（不用实现业务）.

b）在 OrderController 中创建两个端点，分别是 /order/query 和 /order/save

c）给 queryGoods 设置限流规则

d）使用 JMeter 进行测试

1.3、流控效果

1.3.1、快速失败

1.3.2、warm up

a）设置限流规则

b）使用 JMeter 进行测试

c）分析结果

1.3.3、排队等待

a）配置流控规则

b）使用 JMeter 进行测试

c）分析结果

1.3.4、热点参数限流

a）给热点参数限流对象加上 @SentinelResource 注解

c）使用 JMeter 进行测试

d）分析测试结果

一、Sentinel 限流规则

1.1、簇点链路

在 Sentinel 控制台中有这样一个选项.

簇点链路，就是项目内的调用链路.

在 SpringMVC 中，请求先在 Controller 中路由到对应的方法，然后在方法中调用 Sevice 中的方法，最后调用对应的 Mapper 接口，这个过程就是一个调用链路.

链路中被监控的每一个接口就是一个资源（RequestMapping 就是资源路由），默认情况下，会监控 SpringMVC 的每一个端点（也就是 Controller 中的每一个资源），因此 SpringMVC 中每一个端点就是调用链中的一个资源.

流量、熔断等都是针对簇点链路中的资源来设置的.

1.2、流控模式

1.2.1、直接流控模式

在访问 /order/{orderId} 后，打开 Sentinle 控制台，选择 “簇点链路” 就可以看到下图.

点击资源 /order/{orderId} 后面的流控按钮，就会弹出表单，之后就可以添加限流规则.

这里我们先来看一下，直接流控模式（打开高级选项后，即可看到默认选中）

针对来源：默认为 default，也就是对所有的请求有效，这里一般不做修改.
阈值类型：这里就是用 qps 即可，也就是每秒处理请求的最大个数.
单机阈值：设置每秒处理请求的最大个数.
流量模式：这里有三种，当前我们先看第一种，就是统计当前资源的请求，如果超过单机阈值，就进行限流.
流控效果：快速失败是默认，是指到达阈值后，新请求会立刻被拒绝并抛出 FlowException 异常.

这里设置单机阈值为 5.

然后通过 JMeter 测试工具实现每秒中发送 10 个请求，总共持续 2s.

设置 Http 请求

启动脚本，观察运行结果，可以看到差不多是每 5 条成功，5条失败.

在 Sentinel 中就可以观察到QPS 的通过和拒绝情况.

1.2.2、关联流控模式

关联模式：用来统计与当前资源相关的另一个资源，触发阈值时，对当前资源进行限流.

举个例子，你在淘宝上买东西，完成支付以后会进行修改订单状态的业务，与此同时，你还要查看订单，但是查询和修改都会争抢数据库的锁，产生竞争. 根据业务需求是，优先进行更新订单业务，之后进行用户查询业务，因此当修改订单业务触发阈值时，就需要对查询订单业务进行限流.

可以看出，关联流控模式的适用场景满足以下条件：

两个资源有竞争关系.
一个优先级高，一个优先级低.

这里用一个案例来演示：在 OrderController 中创建两个端点，/order/query 和 /order/update ，不用实现业务，接着配置流控规则，当 /order/update 资源被访问的 QPS 超过 5 时，对 /order/query 请求限流.

具体实现步骤如下：

a）在 OrderController 中新建两个端点.

创建 /order/query 和 /order/update 端点.

    @RequestMapping("/query")
    public String queryOrder() {
        return "订单查询成功！";
    }

    @RequestMapping("update")
    public String updateOrder() {
        return "订单修改成功！";
    }

b）在 Sentinel 控制台中对订单查询端点进行流控

单机阈值设置为 5，流控模式选择 “关联”，关联资源就是 /order/update.

也就是说，当 /order/update 达到阈值以后，再发送 /order/query 请求就会抛出异常.

c）使用 JMeter 进行测试

设置每秒发送 10 个请求，总共发 1000 个请求.

这里对 /order/update 发送请求即可.

d）分析结果

JMeter 运行期间，手动发送一个 /order/query 请求，会发现请求失败.

这是因为此时 /order/update 已经超出阈值，此时再发送 /order/query 请求，那么两个请求的总数加起来肯定也是超过阈值的，因此由于设定了 “流控效果” 为快速失败，所以这里抛出异常.

1.2.3、链路流控模式

链路模式：只针对从指定链路访问到当前指定资源的请求做统计，如果超过阈值，则对当前链路进行限流.

例如现在有两条请求链路：

/test1 -> /tools
/test2 -> /tools

如果只希望统计从 /test2 进入 /tools 请求，那么一旦超过阈值（假设阈值为 5），只对此线路进行限流，则可以进行如下配置：

这里用一个案例来演示：现有查询订单和创建订单业务，两者都需要进行查询商品业务. 需求是指针对查询订单 -> 查询商品的请求进行统计并设置流控（阈值为 2）.

具体实现步骤如下：

a）在 OrderService 中添加 queryGoods 方法（不用实现业务）.

用来表示两个查询订单和创建订单两个业务都要访问的查询商品业务.

    @SentinelResource("goods") //设置资源名称
    public void queryGoods() {
        //使用 err 是为了高亮显示，方便观察日志信息
        System.err.println("查询订单成功！");
    }

注意！！！

1. Sentinel 默认值只标记 Controller 中方法为资源，如果想要标记其他方法，需要使用 @SentinelResource 注解来标识资源名.

2. 另外！Sentinel 默认只对 Controller 中的方法做 context 整合，导致链路模式的流控失效，需要 application.yml 中添加如下配置：

spring:
  cloud:
    sentinel:
      web-context-unify: false # 关闭context整合

触发两个端点，就可以看到在 “簇点链路” 中 goods 为两个端点资源的子资源，如下

b）在 OrderController 中创建两个端点，分别是 /order/query 和 /order/save

两个端点中都需要调用 Order Service 中的 queryGoods 方法.

    @RequestMapping("/query")
    public String queryOrder() {
        orderService.queryGoods();
        return "订单查询成功！";
    }

    @RequestMapping("/save")
    public String saveOrder() {
        orderService.queryGoods();
        return "保存订单成功！";
    }

c）给 queryGoods 设置限流规则

针对从 /order/query -> queryGoods 此链路进行限流，阈值为 2.

d）使用 JMeter 进行测试

使用 JMeter 对两个端点都进行每秒发送 4 个请求.

可以看到在 /order/save -> goods 这个链路中请求都成功了.

而 /order/query -> goods 这条链路中，被流控模式限制.

在控制台上也可以看到 goods 的 qps 拒绝情况（每 8 个 qps 中有 2 个被拒绝，拒绝的就是 /order/query 这条链路超过阈值的请求）.

1.3、流控效果

1.3.1、快速失败

快速失败：达到阈值以后，新的请求会立即拒绝并抛出 FlowException 异常，是默认的处理方式

这种方式在演示流控模式中都用是这个效果，这里就不再赘述了.

1.3.2、warm up

warm up：预热模式，对超出阈值的请求同样是拒绝并抛出异常. 但是这种模式的阈值会动态变化，从一个比较小的值逐渐增加到设置的最大阈值（这里的预热时间是需要进行设置的）.

请求阈值的初始值是设置的最大阈值 / coldFactor ，而 coldFactor 默认值是 3.

例如我设置 qps 的最大阈值为 10，预热时间是 5秒，那么初始的阈值就是 10 / 3，取整后就是 3，之后再 5秒以后逐渐增长到 10.

这里我通过一个案例来演示：给 /order/{orderId} 这个资源设置限流，最大 qps 为 10，使用 warm up 效果，预热时常为 5 秒.

具体步骤如下：

a）设置限流规则

b）使用 JMeter 进行测试

c）分析结果

在控制台中可以看到，刚开始的 qps 只通过 3（初始阈值计算后得到的）符合预期，之后 5 秒中内，qps 通过数目逐渐上升，直到 qps 通过数目 = 10 以后稳定下来.

1.3.3、排队等待

排队等待这种方式，当请求超过 qps 阈值之后，不会直接抛出异常，而是让多出来的请求先进入到一个队列中进行排队，然后按照阈值允许的时间间隔依次执行，如果队列中所有的请求处理时间加起来刚好等于等待时间，那么，此时新来的请求就会被拒绝.

例如，设置 qps = 5，意味着每 200ms 处理一个队列中的请求. 如果设置超时时间为 2000ms，那么意味着队列中如果有 10 个请求，就会把时间占满，此时如果再来新的请求，就会被拒绝.

这里用一个案例来演示：给 /order/{orderId} 这个资源设置限流，最大 qps 为 10，利用排队的流控效果，超时时间设置为 5s.

a）配置流控规则

b）使用 JMeter 进行测试

c）分析结果

该开始的时候，都处理成功了是因为新加入的请求都会先进入队列，并且队头的请求也被处理掉了。

而后来的由于请求来的速度大于队列处理的速度，因此队列终有一日会占满超时时间，因此出现了拒绝 qps 的情况.

最后请求请求发完了，队列不停的再处理请求，就不会超过超时时间，因此最后的 qps 全部为通过.

1.3.4、热点参数限流

之前的限流是统计访问某个资源的所有请求，判断是否超过 qps 阈值，而热点参数限流是统计参数值相同的请求，是否超过 qps 阈值.

例如，对 hot 这个资源的 0 号参数（第一个参数）做统计，每 1 秒相同参数的请求数不能超过 5，如下图.

另外，在热点参数限流的高级选项中，还可以对部分参数进行外额限制

参数类型：参数索引指向的参数是什么数据类型（只支持 Java 数据类型）.

参数值：传入的参数值.

限流阈值：窗口时长内，qps 的最大阈值.

例如，如果参数值是 100，则每秒允许的 qps 为 10，如下图.

这里我用一个案例来演示：给 /order/{orderId} 这个资源添加热点参数限流，规则如下：

默认的热点参数规则是每 1 秒请求量不超过 2.
给 102 这个参数设置例外：每 1 秒请求量不超过 4.
给 103 这个参数设置例外：每 1 秒请求量不超过 10.

具体实现步骤如下：

a）给热点参数限流对象加上 @SentinelResource 注解

注意：热点参数限流对默认的 SpringMVC资源无效，因此需要加上 @SentinelResource 指定资源并命名.

    @SentinelResource("hot")
    @GetMapping("{orderId}")
    public Order queryOrderByUserId(@PathVariable("orderId") Long orderId) {
        // 根据id查询订单并返回
        return orderService.queryOrderById(orderId);
    }

b）配置限流规则