Sentinel热点key限流
1、介绍
官网地址:https://github.com/alibaba/Sentinel/wiki/热点参数限流
何为热点?
热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最高的 Top K 数据,并对其访问进行限制。比如:
- 商品 ID 为参数,统计一段时间内最常购买的商品 ID 并进行限制
- 用户 ID 为参数,针对一段时间内频繁访问的用户 ID 进行限制
热点参数限流会统计传入参数中的热点参数,并根据配置的限流阈值与模式,对包含热点参数的资源调用进行限流。热点参数限流可以看做是一种特殊的流量控制,仅对包含热点参数的资源调用生效。
Sentinel 利用 LRU 策略统计最近最常访问的热点参数,结合令牌桶算法来进行参数级别的流控。热点参数限流支持集群模式。
2、热点Key入门实战
2.1、编写8401控制器
注意:新的注解标签
@SentinelResource(value = "testHotKey",blockHandler = "deal_testHotKey")
相当于HystrixCommand
注解的用法,用于代码违背了Sentinel控制台指定的规则后执行的兜底方法,如果程序代码出错那么就会直接在页面显示报错信息,不会执行兜底方法(后面有解决方法)注意:下面使用的是请求参数部署路径参数
@RestController
@Slf4j
public class FlowLimitController {
/**
* 测试热点key接口
* @param p1
* @param p2
* @return
*/
@GetMapping("/testHotKey")
@SentinelResource(value = "testHotKey",blockHandler = "dealHandler_testHotKey")
public String testHotKey(@RequestParam(value = "p1",required = false) String p1,
@RequestParam(value = "p2",required = false) String p2){
return "------testHotKey";
}
/**
* 热点key报错兜底方法
* @param p1
* @param p2
* @param exception
* @return
*/
public String dealHandler_testHotKey(String p1,String p2,BlockException exception)
{
return "-----dealHandler_testHotKey";
}
}
2.2、Sentinel配置热点key
需要访问一次
http://localhost:8401/testHotKey?p1=1
的控制器接口,然后才会在Sentinel中显示出簇点链路
根据上面的控制器指定的请求参数,索引为0的参数是
p1
,所以只要请求的路径中有p1这个请求参数都会被设置的规则进行限流,限流的就会执行兜底放法
2.3、测试
- 单机测试(1秒一个QPS):http://localhost:8401/testHotKey?p1=zhangsan&p2=lishi
正常返回
-------- testHotKey
-
快速测试(1秒2个QPS):http://localhost:8401/testHotKey?p1=zhangsan
输出兜底方法
-----dealHandler_testHotKey
如果使用
@SentinelResource(value = "testHotKey")
注解不指定兜底方法blockHandler = "dealHandler_testHotKey"
当前台访问的时候就会直接在页面上显示报错信息(不友好),一定要加上blockHandler
指定兜底方法
3、热带Key参数例外项
配置说明:
上面的
参数索引
为0,说的就是现在第一个请求参数,并且QPS是1参数例外项:指定参数的具体值是什么,以及对该参数的阈值是多少,例如索引为0的参数
p1=1
那么久符合了参数值是1,那他的限流阈值久可以达到一秒钟QPS200个的请求,如果参数不是1,那么p1的请求限制QPS就是一秒钟一个
通过压测工具1秒200个QPS请求接口对比实时监控
访问正常的p1参数
拒绝的SQP很多,通过的久2个左右
访问指定参数的p1=1
通过的QPS差不多201个
4、系统规则
官网地址:https://github.com/alibaba/Sentinel/wiki/系统自适应限流
Sentinel 系统自适应限流从整体维度对应用入口流量进行控制,结合应用的 Load、CPU 使用率、总体平均 RT、入口 QPS 和并发线程数等几个维度的监控指标,通过自适应的流控策略,让系统的入口流量和系统的负载达到一个平衡,让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。
4.1、系统规则
系统保护规则是从应用级别的入口流量进行控制,从单台机器的 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 达到阈值即触发系统保护。
4.2、系统规则入门
之前的规则指定都是指定某一个接口的而这个就是指定整个系统的入口做限制,只要接口的SQP1秒钟超过了1SQP就会进行拦截,不管是谁