从kratos分析BBR限流源码实现

最新推荐文章于 2024-10-19 09:52:25 发布

原创

最新推荐文章于 2024-10-19 09:52:25 发布 · 1.1k 阅读

13 ·

CC 4.0 BY-SA版权

文章标签：

#网络 #数据库

什么是自适应限流

自适应限流从整体维度对应用入口流量进行控制，结合应用的 Load、CPU 使用率、总体平均 RT、入口 QPS 和并发线程数等几个维度的监控指标，通过自适应的流控策略，让系统的入口流量和系统的负载达到一个平衡，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。

核心目标：

自动嗅探负载和 qps，减少人工配置
削顶，保证超载时系统不被拖垮，并能以高水位 qps 继续运行

限流规则

计算吞吐量：利特尔法则 L = λ * W

如上图所示，如果我们开一个小店，平均每分钟进店 2 个客人(λ)，每位客人从等待到完成交易需要 4 分钟(W)，那我们店里能承载的客人数量就是 2 * 4 = 8 个人

同理，我们可以将 λ 当做 QPS， W 呢是每个请求需要花费的时间，那我们的系统的吞吐就是 L = λ * W ，所以我们可以使用利特尔法则来计算系统的吞吐量。

指标介绍

指标名称	指标含义
cpu	最近 1s 的 CPU 使用率均值，使用滑动平均计算，采样周期是 250ms
inflight	当前处理中正在处理的请求数量
pass	请求处理成功的量
rt	请求成功的响应耗时

滑动窗口

在自适应限流保护中，采集到的指标的时效性非常强，系统只需要采集最近一小段时间内的 qps、rt 即可，对于较老的数据，会自动丢弃。为了实现这个效果，kratos 使用了滑动窗口来保存采样数据。

如上图，展示了一个具有两个桶（bucket）的滑动窗口（rolling window）。整个滑动窗口用来保存最近 1s 的采样数据，每个小的桶用来保存 500ms 的采样数据。当时间流动之后，过期的桶会自动被新桶的数据覆盖掉，在图中，在 1000-1500ms 时，bucket 1 的数据因为过期而被丢弃，之后 bucket 3 的数据填到了窗口的头部。

限流公式

判断是否丢弃当前请求的算法如下：

cpu > 800 AND (Now - PrevDrop) < 1s AND (MaxPass * MinRt * windows / 1000) < InFlight

MaxPass 表示最近 5s 内，单个采样窗口中最大的请求数。 MinRt 表示最近 5s 内，单个采样窗口中最小的响应时间。 windows 表示一秒内采样窗口的数量，默认配置中是 5s 50 个采样，那么 windows 的值为 10。

源码分析

代码地址：

https://github.com/go-kratos/aegis/tree/main/ratelimit/bbr

BBR struct

type BBR struct {
   
   
	cpu             cpuGetter
	passStat        window.RollingCounter
	rtStat          window.RollingCounter
	inFlight        int64
	bucketPerSecond int64
	bucketSize      time.Duration

	// prevDropTime defines previous start drop since initTime
	prevDropTime atomic.Value
	maxPASSCache atomic.Value
	minRtCache   atomi