SpringCloud第十八章AlibabaSentinel实现熔断与限流（流控规则）

4、流控规则

4.1、基本介绍

4.2、流控模式

• 直接(默认)

  • 直接->快速失败 系统默认

  • 配置及说明

    表示1秒钟内查询1次就是OK，若超过次数1，就直接-快速失败，报默认错误

    

  • 测试

    • 快速点击访问http://localhost:8401/testA

    • 结果

      Blocked by Sentinel (flow limiting)

    • 思考???

      直接调用默认报错信息，技术方面OK，but,是否应该有我们自己的后续处理?

      类似有个fallback的兜底方法？

• 关联

  • 是什么

    • 当关联的资源达到阈值时，就限流自己
    • 当与A关联的资源B达到阀值后，就限流A自己
    • B惹事，A挂了

  • 配置A

    设置效果
    当关联资源/testB的qps阀值超过1时，就限流/testA的Rest访问地址，当关联资源到阈值后限制配置好的资源名

    

  • postman模拟并发密集访问testB

    

  • 访问testB成功

    

  • postman里新建多线程集合组

    

  • 将访问地址添加进新新线程组

    

  • Run

    

  大批量线程高并发访问B，导致A失效了
  

  • 运行后发现testA挂了

    • 点击访问http://localhost:8401/testA

    • 结果

      Blocked by Sentinel (flow limiting)

• 链路

  • 多个请求调用了同一个微服务
  • 待完成

4.3、流控效果

• 直接->快速失败(默认的流控处理)

  • 直接失败，抛出异常 Blocked by Sentinel (flow limiting)
  • 源码 com.alibaba.csp.sentinel.slots.block.flow.controller.DefaultController

• 预热

  • 说明

    公式：阈值除以coldFactor(默认值为3),经过预热时长后才会达到阈值

  • 官网

    https://github.com/alibaba/Sentinel/wiki/%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6

    

  • 默认coldFactor为3，即请求 QPS 从 threshold / 3 开始，经预热时长逐渐升至设定的 QPS 阈值。

  • 限流 冷启动

    https://github.com/alibaba/Sentinel/wiki/%E9%99%90%E6%B5%81—%E5%86%B7%E5%90%AF%E5%8A%A8

  • 源码 com.alibaba.csp.sentinel.slots.block.flow.controller.WarmUpController

  • WarmUp配置

    • 默认 coldFactor 为 3，即请求QPS从(threshold / 3) 开始，经多少预热时长才逐渐升至设定的 QPS 阈值。

    • 案例，阀值为10+预热时长设置5秒。
      系统初始化的阀值为10 / 3 约等于3,即阀值刚开始为3；然后过了5秒后阀值才慢慢升高恢复到10

      

  • 多次点击http://localhost:8401/testB

    刚开始不行，后续慢慢OK

  • 应用场景

    如：秒杀系统在开启的瞬间，会有很多流量上来，很有可能把系统打死，预热方式就是把为了保护系统，可慢慢的把流量放进来，慢慢的把阀值增长到设置的阀值。

• 排队等待

  匀速排队，让请求以均匀的速度通过，阀值类型必须设成QPS，否则无效。

  设置含义：/testA每秒1次请求，超过的话就排队等待，等待的超时时间为20000毫秒。

  

  • 匀速排队，阈值必须设置为QPS

    

  • 官网

    https://github.com/alibaba/Sentinel/wiki/%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6

  • 源码 com.alibaba.csp.sentinel.slots.block.flow.controller.RateLimiterController

  • 测试