前言
在讲解滑动时间窗之前，有个问题可以思考一下，如何统计当前时间服务的QPS呢？博主在前公司的时候，他们是这么设计的，在分布式环境下，列如当前时间 2021-9-13 23：12：10， 那么解析成key = 2021-9-13-23-12-10,并通过这个key查询redis，获取一个整型的统计值，并执行incr自增。当到下一个时间2021-9-13 23：12：11，则生成key=2021-9-13-23-12-11.从redis中获取一个新的计数器，并incr。
这有什么问题？
1） 随着时间的增长，redis中的key越来越多
2）23时12分10秒600毫秒 与 23时12分11秒600毫秒 这1秒期间，QPS的值将无法统计。
滑动时间窗算法
1 我们把当前的时间看做一个无限延长的有向轴，并且分隔成一个个固定单位，这个固定单位成为时间窗，可以是1s，也可以是1min。为了便于统计一分钟内或者1秒钟内的QPS,将单位时间窗划分为多个样本时间窗。
2 划分样本时间窗的目的是 为了避免重复统计，列如当时间运行到样本窗7 ，则需要统计样本窗4-7。 下次如果当前时间到了样本窗8，则需要统计5-8，而中间的5-7已经统计过了，只需要再加上样本窗8中的数据。
3 在sentinel中，缓存了一个单位时间窗的统计数据，并组织成一个环，实际上就是通过对样本窗口数取余来确定请求落在哪个样本窗上。
4 使用了滑动时间窗算法之后，获取的QPS永远统计的是当前时间之前的一个单位时间窗的统计结果，也解决了在前言中的问题2.
源码解析
整个Sentinel是按着责任链模式来组织架构的，在chain上的slot，StatisticSlot#entry里面，先根据之前的统计执行下面的slot，比如FlowSlot，根据流控结果来统计当前请求是否成功或者失败。
// Do some checking.
// 先做其他的slot
fireEntry(context, resourceWrapper, node, count, prioritized, args);
// Request passed, add thread count and pass count.
node.increaseThreadNum();
// 对当前的资源DefaultNode添加统计
node.addPassRequest(count);
if (context.getCurEntry().getOriginNode() != null) {
// Add count for origin node.
context.getCurEntry().getOriginNode().increaseThreadNum();
// 对所有相同资源和相同来源。不同的context上的同一个originNode做统计
context.getCurEntry().getOriginNode().addPassRequest(count);
}统计的维度有这么几个，1 对于当前请求在指定资源上的DefaultNode的统计 2指定资源上上全局的clusterNode的统计。代码如下node.addPassRequest(count)
@Override
public void addPassRequest(int count) {
// 增加当前入口的defaultNode中的统计数据
super.addPassRequest(count);
// 增加当前资源的clusterNode中全局统计数据
this.clusterNode.addPassRequest(count);
}3 对于相同资源的全局CluserNode在指定来源上的统计 ，比如 全局统计资源A在来源A上的QPS ，代码 context.getCurEntry().getOriginNode().addPassRequest(count);
@Override
public void addPassRequest(int count) {
// 为滑动计数器增加本次访问的计数器
rollingCounterInSecond.addPass(count);
rollingCounterInMinute.addPass(count);
}入口已经讲解完毕，接下来具体从阐述数据结构及算法核心逻辑。
在StatisticsNode里面有2个重要的计量器，一个是单位时间窗以秒为单位，一个单位时间窗是分为单位
/**
* Holds statistics of the recent {@code INTERVAL} milliseconds. The {@code INTERVAL} is divided into time spans
* by given {@code sampleCount}.
* 定义一个使用数组保存数据的计量器
*/
private transient volatile Metric rollingCounterInSecond = new ArrayMetric(SampleCountProperty.SAMPLE_COUNT /* 样本窗口数量 默认2 */,
IntervalProperty.INTERVAL /* 时间窗长度 默认1s */);
/**
* Holds statistics of the recent 60 seconds. The windowLengthInMs is deliberately set to 1000 milliseconds,
* meaning each bucket per second, in this way we can get accurate statistics of each second.
*/
private transient Metric rollingCounterInMinute = new ArrayMetric(60, 60 * 1000, false);在讲解之前可以看一下数据结构是如何设计的，实际上一个计量器内部维护这一个数组，即单位时间窗，元素为一个样本窗口对象windowWrap，一个样本窗口维护这一个MetricBucket类型的值变量.
数据结构
addPass
public void addPass(int count) {
// 获取当前时间点所在的样本窗口
WindowWrap<MetricBucket> wrap = data.currentWindow();
// 在样本窗中增加count
wrap.value().addPass(count);
}这里面最关键是如何根据当前时间来获取在单位时间窗内的样本窗，先计算出当前时间在单位时间窗内的样本窗位置.
// 计算当前时间在哪个样本窗口
private int calculateTimeIdx(/*@Valid*/ long timeMillis) {
long timeId = timeMillis / windowLengthInMs;
// Calculate current index so we can map the timestamp to the leap array.
// 一个时间窗组成一个环，该环由多个样本窗口组成
return (int)(timeId % array.length());
}然后根据idx来获取到样本窗对象，比较样本窗开始时间来确认是否过时
public WindowWrap<T> currentWindow(long timeMillis) {
if (timeMillis < 0) {
return null;
}
// 计算当前时间所在的样本窗口ID，即在计算数组leapArray中的索引
// 这个idx不会超过样本数量
int idx = calculateTimeIdx(timeMillis);
// Calculate current bucket start time.
// 获取当前时间对应的样本窗口的起始时间戳
long windowStart = calculateWindowStart(timeMillis);
/*
* Get bucket item at given time from the array.
*
* (1) Bucket is absent, then just create a new bucket and CAS update to circular array.
* (2) Bucket is up-to-date, then just return the bucket.
* (3) Bucket is deprecated, then reset current bucket and clean all deprecated buckets.
*/
while (true) {
// 获取到当前时间所在的样本窗口
WindowWrap<T> old = array.get(idx);
if (old == null) {
/*
* B0 B1 B2 NULL B4
* ||_______|_______|_______|_______|_______||___
* 200 400 600 800 1000 1200 timestamp
* ^
* time=888
* bucket is empty, so create new and update
*
* If the old bucket is absent, then we create a new bucket at {@code windowStart},
* then try to update circular array via a CAS operation. Only one thread can
* succeed to update, while other threads yield its time slice.
*/
WindowWrap<T> window = new WindowWrap<T>(windowLengthInMs, windowStart, newEmptyBucket(timeMillis));
if (array.compareAndSet(idx, null, window)) {
// Successfully updated, return the created bucket.
return window;
} else {
// Contention failed, the thread will yield its time slice to wait for bucket available.
Thread.yield();
}
} else if (windowStart == old.windowStart()) {
/*
* B0 B1 B2 B3 B4
* ||_______|_______|_______|_______|_______||___
* 200 400 600 800 1000 1200 timestamp
* ^
* time=888
* startTime of Bucket 3: 800, so it's up-to-date
*
* If current {@code windowStart} is equal to the start timestamp of old bucket,
* that means the time is within the bucket, so directly return the bucket.
*/
return old;
} else if (windowStart > old.windowStart()) {
// 在idx上的样本时间窗可能已经老了，可能是上几圈的idx位置，本线程的windowStart 已经到了后面圈的样本时间窗了
/*
* (old)
* B0 B1 B2 NULL B4
* |_______||_______|_______|_______|_______|_______||___
* ... 1200 1400 1600 1800 2000 2200 timestamp
* ^
* time=1676
* startTime of Bucket 2: 400, deprecated, should be reset
*
* If the start timestamp of old bucket is behind provided time, that means
* the bucket is deprecated. We have to reset the bucket to current {@code windowStart}.
* Note that the reset and clean-up operations are hard to be atomic,
* so we need a update lock to guarantee the correctness of bucket update.
*
* The update lock is conditional (tiny scope) and will take effect only when
* bucket is deprecated, so in most cases it won't lead to performance loss.
*/
if (updateLock.tryLock()) {
try {
// Successfully get the update lock, now we reset the bucket.
return resetWindowTo(old, windowStart);
} finally {
updateLock.unlock();
}
} else {
// Contention failed, the thread will yield its time slice to wait for bucket available.
Thread.yield();
}
} else if (windowStart < old.windowStart()) {
// 这种情况一般不会出现 除非人为改动
// Should not go through here, as the provided time is already behind.
return new WindowWrap<T>(windowLengthInMs, windowStart, newEmptyBucket(timeMillis));
}
}
}
这时候已经完成了统计工作，那么在流量控制FlowSlot中是如何的实现QPS查询呢？
FlowSlot#entry -> FlowRuleChecker#checkFlow -> FlowRuleChecker#canPassCheck -> DefaultController#canPass -> DefaultController#avgUsedTokens -> node.passQps()
获取计量数中的通过数 除以 单位时间窗长度
@Override
public double passQps() {
return rollingCounterInSecond.pass() / rollingCounterInSecond.getWindowIntervalInSec();
}接下来看一下如何获取单位时间窗内的请求量
实际上就是把有效的样本时间窗内的各个统计量相加
@Override
public long pass() {
// 更新array中当前时间点所在的样本窗口实例中的数据
data.currentWindow();
long pass = 0;
List<MetricBucket> list = data.values();
// 将当前时间窗中的所有样本窗口统计的值求和
for (MetricBucket window : list) {
pass += window.pass();
}
return pass;
}在拿样本时间窗的时候，需要拿有效的样本，不能包含过时的
public List<T> values(long timeMillis) {
if (timeMillis < 0) {
return new ArrayList<T>();
}
int size = array.length();
List<T> result = new ArrayList<T>(size);
for (int i = 0; i < size; i++) {
WindowWrap<T> windowWrap = array.get(i);
// 判断样本窗是否过时： 当前时间-windowsStart > intervalInms
if (windowWrap == null || isWindowDeprecated(timeMillis, windowWrap)) {
// 有可能这个时间窗口 没有请求，在一个时间窗的时候 发现这个样本窗已经过时
continue;
}
result.add(windowWrap.value());
}
return result;
}
LeapArray有2个实现类，分别是OccupiableBucketLeapArray (单位时间窗为1s)和 BucketLeapArray(单位时间窗为1min)，那么这两个实现类有什么区别的。实际上对于OccupiableBucketLeapArray，如果是优先级较高，同时流控的时候超过了配置的阈值，那么可以等待一定的时间，使用未来的配额，保证通过流控。
DefaultController#canPass()
@Override
public boolean canPass(Node node, int acquireCount, boolean prioritized) {
int curCount = avgUsedTokens(node);
if (curCount + acquireCount > count) { // 被流控
// 如果流控策略是基于QPS 并且优先级较高
if (prioritized && grade == RuleConstant.FLOW_GRADE_QPS) {
long currentTime;
long waitInMs;
currentTime = TimeUtil.currentTimeMillis();
waitInMs = node.tryOccupyNext(currentTime, acquireCount, count);
if (waitInMs < OccupyTimeoutProperty.getOccupyTimeout()) {
// 添加占用未来时间对应的样本窗的pass配额
node.addWaitingRequest(currentTime + waitInMs, acquireCount);
// 统计 OccupiedPass
node.addOccupiedPass(acquireCount);
sleep(waitInMs);
// PriorityWaitException indicates that the request will pass after waiting for {@link @waitInMs}.
throw new PriorityWaitException(waitInMs);
}
}
return false;
}
return true;
}那么如何确定等待的时间呢？
在上面的代码中有个比较 waitInMs < OccupyTimeoutProperty.getOccupyTimeout()，这说明就是因为当前样本窗的pass数量太多造成的，这个时间只要sleep 剩余样本窗是的时间就可以了。
而等待时间超过500的情况下，说明之前的样本窗就已经超过阈值了，这个时候不允许通过流量控制，返回false。
public long tryOccupyNext(long currentTime, int acquireCount, double threshold) {
double maxCount = threshold * IntervalProperty.INTERVAL / 1000;
// 0
long currentBorrow = rollingCounterInSecond.waiting();
if (currentBorrow >= maxCount) {
return OccupyTimeoutProperty.getOccupyTimeout();
}
// 500
int windowLength = IntervalProperty.INTERVAL / SampleCountProperty.SAMPLE_COUNT;
/**
* 这个算法 是获取当前时间对应的样本窗的结束时间 往前推一个单位时间窗 来获取到一个能统计到当前时间对应的样本窗的最早时间
*/
long earliestTime = currentTime - currentTime % windowLength + windowLength - IntervalProperty.INTERVAL;
int idx = 0;
/*
* Note: here {@code currentPass} may be less than it really is NOW, because time difference
* since call rollingCounterInSecond.pass(). So in high concurrency, the following code may
* lead more tokens be borrowed.
*/
// 当前时间单位窗口的统计数
long currentPass = rollingCounterInSecond.pass();
/**
* 这块逻辑很好理解：
* 从最早时间 到 当前时间为止
* 初始等待时间为 当前时间对应的样本窗，剩余的时间长度
* 如果去掉最早样本窗的pass数之后，发现仍然大于阈值 ，则等待时间数 + 样本时间窗长度
*/
while (earliestTime < currentTime) {
long waitInMs = idx * windowLength + windowLength - currentTime % windowLength;
if (waitInMs >= OccupyTimeoutProperty.getOccupyTimeout()) {
break;
}
long windowPass = rollingCounterInSecond.getWindowPass(earliestTime);
if (currentPass + currentBorrow + acquireCount - windowPass <= maxCount) {
return waitInMs;
}
earliestTime += windowLength;
currentPass -= windowPass;
idx++;
}
return OccupyTimeoutProperty.getOccupyTimeout();
}
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
