Sentinel 热点参数限流

https://github.com/alibaba/Sentinel/wiki/%E7%83%AD%E7%82%B9%E5%8F%82%E6%95%B0%E9%99%90%E6%B5%81

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

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

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

Sentinel Parameter Flow Control

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

热点参数规则

热点参数规则（ParamFlowRule）类似于流量控制规则（FlowRule）：

属性	说明	默认值
resource	资源名，必填
count	限流阈值，必填
grade	限流模式	QPS 模式
durationInSec	统计窗口时间长度（单位为秒），1.6.0 版本开始支持	1s
controlBehavior	流控效果（支持快速失败和匀速排队模式），1.6.0 版本开始支持	快速失败
maxQueueingTimeMs	最大排队等待时长（仅在匀速排队模式生效），1.6.0 版本开始支持	0ms
paramIdx	热点参数的索引，必填，对应 `SphU.entry(xxx, args)` 中的参数索引位置
paramFlowItemList	参数例外项，可以针对指定的参数值单独设置限流阈值，不受前面 `count` 阈值的限制。仅支持基本类型和字符串类型
clusterMode	是否是集群参数流控规则	`false`
clusterConfig	集群流控相关配置

package com.wsm.order.controller;

import com.alibaba.csp.sentinel.annotation.SentinelResource;
import com.alibaba.csp.sentinel.slots.block.BlockException;
import com.wsm.order.service.OrderService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.concurrent.TimeUnit;

@RestController
@RequestMapping("/order")
public class OrderController {

    @Autowired
    OrderService orderService;

    @RequestMapping("/add")
    public String add(){
        System.out.println("下单成功！");
        return "生成订单";
    }

    @RequestMapping("/get")
    public String get(){
        System.out.println("查询订单！");
        return "查询订单";
    }

    @RequestMapping("/test1")
    public String test1(){
        return orderService.getUser();
    }

    @RequestMapping("/test2")
    public String test2(){
        return orderService.getUser();
    }

    @RequestMapping("/flow")
//    @SentinelResource(value = "flow",blockHandler = "flowBlockHandler")
    public String flow(){
        System.out.println("========flow====");
        return "正常访问";
    }

    public String flowBlockHandler(BlockException e){
        return "流控了";
    }

    @RequestMapping("/flowThread")
//    @SentinelResource(value = "flowThread",blockHandler = "flowThreadBlockHandler")
    public String flowThread() throws InterruptedException {
        TimeUnit.SECONDS.sleep(5);
        System.out.println("flowThread正常访问");
        return "正常访问";
    }

    public String flowThreadBlockHandler(BlockException e){
        return "flowThread流控了";
    }

    @RequestMapping("/err")
    public String err() {
        int a=1/0;
        return "err";
    }

    @RequestMapping("/get/{id}")
    @SentinelResource(value = "getById", blockHandler = "HotBlockHandler")
    public String getById(@PathVariable("id") Integer id) {
        System.out.println("正常访问:"+id);
        return "正常访问:"+id;
    }

    public String HotBlockHandler(@PathVariable("id") Integer id,BlockException e) {
        return "热点异常处理"+id;
    }

}

单机阈值：

1、假设参数大部分值都是热点参数，那单机阈值就主要针对热点参数进行流控。后续再额外针对普通的参数进行流控。

2、假设参数大部分值都是普通流量，那单机阈值就主要针对普通参数进行流控。

（统计窗口时长）内的QPS （单机阈值）

系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间

QPS（Query Per Second），QPS 其实是衡量吞吐量（Throughput）的一个常用指标，就是说服务器在一秒的时间内处理了多少个请求 —— 我们通常是指 HTTP 请求，显然数字越大代表服务器的负荷越高、处理能力越强。作为参考，一个有着简单业务逻辑（包括数据库访问）的程序在单核心运行时可以提供 50 - 100 左右的 QPS，即每秒可以处理 50 - 100 个请求。
TPS(Transaction Per Second) 每秒钟系统能够处理的事务的数量。

QPS（TPS）：每秒钟 request/事务的数量（此处 / 表示或的意思）

并发数：系统同时处理的request/事务数（此处 / 表示或的意思）

响应时间：一般取平均响应时间

理解了上面三个要素的意义之后，就能推算出它们之间的关系：

QPS（TPS）= 并发数/平均响应时间

一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。

并发用户数和QPS两个概念没有直接关系，但是如果要说QPS时，一定需要指明是多少并发用户数下的QPS，否则毫无意义，因为单用户数的400QPS和200并发用户数下的400QPS是两个不同的概念。前者说明该应用可以在一秒内串行执行400个请求，而后者说明在并发200个请求的情况下，一秒内该应用能处理400个请求，当QPS相同时，越大的并发用户数，代表了网站并发处理能力越好。对于当前的web服务器，其处理单个用户的请求肯定戳戳有余，这个时候会存在资源浪费的情况（一方面该服务器可能有多个cpu，但是只处理单个进程，另一方面，在处理一个进程中，有些阶段可能是IO阶段，这个时候会造成CPU等待，但是有没有其他请求进程可以被处理）。而当并发数设置的过大时，每秒钟都会有很多请求需要处理，会造成进程（线程）频繁切换，反正真正用于处理请求的时间变少，每秒能够处理的请求数反而变少，同时用户的请求等待时间也会变大，甚至超过用户的心理底线。所以在最小并发数和最大并发数之间，一定有一个最合适的并发数值，在该并发数下，QPS能够达到最大。但是，这个并发并非是一个最佳的并发，因为当QPS到达最大时的并发，可能已经造成用户的等待时间变得超过了其最优值，所以对于一个系统，其最佳的并发数，一定需要结合QPS，用户的等待时间来综合确定。