You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
58 lines
2.5 KiB
58 lines
2.5 KiB
6 years ago
|
# 自适应限流保护
|
||
|
|
|
||
|
|
kratos 借鉴了 Sentinel 项目的自适应限流系统，通过综合分析服务的 cpu 使用率、请求成功的 qps 和请求成功的 rt 来做自适应限流保护。
|
||
|
|
|
||
|
|
|
||
|
|
## 核心目标
|
||
|
|
|
||
|
|
* 自动嗅探负载和 qps，减少人工配置
|
||
|
|
* 削顶，保证超载时系统不被拖垮，并能以高水位 qps 继续运行
|
||
|
|
|
||
|
|
|
||
|
|
## 限流规则
|
||
|
|
|
||
|
|
1，指标介绍
|
||
|
|
|
||
|
|
|指标名称|指标含义|
|
||
|
|
|---|---|
|
||
|
|
|cpu|最近 1s 的 CPU 使用率均值，使用滑动平均计算，采样周期是 250ms|
|
||
|
|
|inflight|当前处理中正在处理的请求数量|
|
||
|
|
|pass|请求处理成功的量|
|
||
|
|
|rt|请求成功的响应耗时|
|
||
|
|
|
||
|
|
|
||
|
|
2，滑动窗口
|
||
|
|
|
||
|
|
在自适应限流保护中，采集到的指标的时效性非常强，系统只需要采集最近一小段时间内的 qps、rt 即可，对于较老的数据，会自动丢弃。为了实现这个效果，kratos 使用了滑动窗口来保存采样数据。
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
如上图，展示了一个具有两个桶（bucket）的滑动窗口（rolling window）。整个滑动窗口用来保存最近 1s 的采样数据，每个小的桶用来保存 500ms 的采样数据。
|
||
|
|
当时间流动之后，过期的桶会自动被新桶的数据覆盖掉，在图中，在 1000-1500ms 时，bucket 1 的数据因为过期而被丢弃，之后 bucket 3 的数据填到了窗口的头部。
|
||
|
|
|
||
|
|
|
||
|
|
3，限流公式
|
||
|
|
|
||
|
|
判断是否丢弃当前请求的算法如下：
|
||
|
|
|
||
|
|
`cpu > 800 AND (Now - PrevDrop) < 1s AND (MaxPass * MinRt * windows / 1000) < InFlight`
|
||
|
|
|
||
|
|
MaxPass 表示最近 5s 内，单个采样窗口中最大的请求数。
|
||
|
|
MinRt 表示最近 5s 内，单个采样窗口中最小的响应时间。
|
||
|
|
windows 表示一秒内采样窗口的数量，默认配置中是 5s 50 个采样，那么 windows 的值为 10。
|
||
|
|
|
||
|
|
## 压测报告
|
||
|
|
|
||
|
|
场景1，请求以每秒增加1个的速度不停上升，压测效果如下：
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
左测是没有限流的压测效果，右侧是带限流的压测效果。
|
||
|
|
可以看到，没有限流的场景里，系统在 700qps 时开始抖动，在 1k qps 时被拖垮，几乎没有新的请求能被放行，然而在使用限流之后，系统请求能够稳定在 600 qps 左右，rt 没有暴增，服务也没有被打垮，可见，限流有效的保护了服务。
|
||
|
|
|
||
|
|
|
||
|
|
参考资料：
|
||
|
|
|
||
|
|
[Sentinel 系统自适应限流](https://github.com/alibaba/Sentinel/wiki/%E7%B3%BB%E7%BB%9F%E8%87%AA%E9%80%82%E5%BA%94%E9%99%90%E6%B5%81)
|
||
|
|
|