前面两篇文章分别介绍了Sentinel怎么用，QPS怎么计算，接下来介绍下Sentinel限流策略
Alibaba Sentinel限流功能
Alibaba Sentinel与滑动时间窗口
Sentinel限流策略接口定义在 TrafficShapingController中，核心方法canPass，实现是否将流量放行的逻辑。
public interface TrafficShapingController {
boolean canPass(Node node, int acquireCount, boolean prioritized);
boolean canPass(Node node, int acquireCount);
}
其有四种实现，分别是基于QPS绝对值的DefaultController，基于频率的RateLimiterController，以及在这两大类之上构建出的，考虑冷启动问题的WarmUpController，WarmUpRateLimiterController
DefaultController
DefaultController是Sentinel默认的策略，核心逻辑是计算出当前时间窗口的count，满足qps要求就放行，不满足（prioritized=true）可以借未来时间窗口的quota,如果都不ok，则直接拒绝，详见下述代码注释1，2，3
public boolean canPass(Node node, int acquireCount, boolean prioritized) {
//1.计算当前窗口计数之和
int curCount = avgUsedTokens(node);
//2.比较当前流量与规则限制
if (curCount + acquireCount > count) {
//3.即使超限，如果prioritized设为true，则认为是重要业务，可以尝试让业务线程sleep到下一个窗口，借用下一个窗口的计数
if (prioritized && grade == RuleConstant.FLOW_GRADE_QPS) {
long currentTime;
long waitInMs;
currentTime = TimeUtil.currentTimeMillis();
waitInMs = node.tryOccupyNext(currentTime, acquireCount, count);
if (waitInMs < OccupyTimeoutProperty.getOccupyTimeout()) {
node.addWaitingRequest(currentTime + waitInMs, acquireCount);
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;
}
RateLimiterController
这是一种基于频率的限流策略，DefaultController关注的是QPS的绝对值，而RateLimiterController关注的是流量进来的间隔时间，如果定义QPS阈值为10，使用DefaultController的策略，无论流量在一秒内的某个ms单位时间点同时进来，还是均匀的每100ms进来一个请求，都是一视同仁的，都可以通过。使用RateLimiterControlle策略，则要求每一个请求，距离上一次请求通过的间隔，必须大于等于100ms，才可以放行，否则必须sleep一段时间，直到间隔大于等于100ms，否则拒绝。可以认为这是一种基于固定频率的限流机制。
见代码
public boolean canPass(Node node, int acquireCount, boolean prioritized) {
long currentTime = TimeUtil.currentTimeMillis();
// Calculate the interval between every two requests.
long costTime = Math.round(1.0 * (acquireCount) / count * 1000);
// Expected pass time of this request.
long expectedTime = costTime + latestPassedTime.get();
//比如预期下一个请求在1500ms之后到来，currentTime已经在1600ms，表名系统其实是闲着的，直接通过即可。
if (expectedTime <= currentTime) {
// Contention may exist here, but it's okay.
latestPassedTime.set(currentTime);
return true;
} else {//计算需要等的时间
long waitTime = costTime + latestPassedTime.get() - TimeUtil.currentTimeMillis();
//等待时间过长，直接拒绝
if (waitTime > maxQueueingTimeMs) {
return false;
} else {//等的时间ok，考虑放行，去抢占更新latestPassedTime
long oldTime = latestPassedTime.addAndGet(costTime);
try {
waitTime = oldTime - TimeUtil.currentTimeMillis();
//说明抢占失败了，而且新的等待时间无法接受，则回滚更新，拒绝
if (waitTime > maxQueueingTimeMs) {
latestPassedTime.addAndGet(-costTime);
return false;
}
//sleep之后放行。
if (waitTime > 0) {
Thread.sleep(waitTime);
}else{
System.out.print("waitTime <=0 "+waitTime);
}
return true;
} catch (InterruptedException e) {
}
}
}
return false;
}
WarmUpController
部分业务系统，当启动完毕，或者长期处于低负荷状态运行时，会因为资源初始化（比如数据库建立连接，远程网络连接）的问题，无法应对突如其来的大流量。WarmUpController提供的限流策略，支持系统在一个时间段，以一个曲线爬坡，逐步增加系统QPS限制，达到WarmUp的效果。warmup完毕之后，其限流策略与DefaultController相似。
public boolean canPass(Node node, int acquireCount, boolean prioritized) {
long passQps = (long) node.passQps();
long previousQps = (long) node.previousPassQps();
syncToken(previousQps);
// 开始计算它的斜率
// 如果进入了警戒线，开始调整他的qps
long restToken = storedTokens.get();
// 这种情况相当于冷状态
if (restToken >= warningToken) {
long aboveToken = restToken - warningToken;
// 消耗的速度要比warning快，但是要比慢
// current interval = restToken*slope+1/count
double warningQps = Math.nextUp(1.0 / (aboveToken * slope + 1.0 / count));
if (passQps + acquireCount <= warningQps) {
return true;
}
} else {// 这种情况相当于热状态
if (passQps + acquireCount <= count) {
return true;
}
}
return false;
}
这种策略将限流器模拟为token桶，QPS如果限制为20，则认为每秒自动往桶里加20个token，每通过一个请求，从桶里拿走一个token。
这种WarmUp策略的关键逻辑有两个：
1.判断系统怎么样算冷状态。
2.warmUp爬坡的坡度。
相关的公式见下。WarmUpController默认的coldFactor=3，如果定义冷启动时间10s，最大QPS为20。则可以得出warningToken=100，maxToken= 200 slope = 0.001
通俗的讲，在这种定义下，流量进来拿token的速度如果很慢，桶里剩余token大于等于100，则认为是冷状态，走冷状态的爬坡限流机制，会从6.66QPS在10s钟的时间内爬升到20QPS的流控限制。
warningToken = (int)(warmUpPeriodInSec * count) / (coldFactor - 1);
maxToken = warningToken + (int)(2 * warmUpPeriodInSec * count / (1.0 + coldFactor));
slope = (coldFactor - 1.0) / count / (maxToken - warningToken);
WarmUpRateLimiterController
这种策略可以认为是基于频率限流RateLimiterController的WarmUp版，也是以一个较低初始频率，逐步爬坡到目标频率。其实现类继承自WarmUpController，各种指标计算公式完成复用的，只是把WarmUpController计算得出的qps转换成频率进行限流。比如冷启动时间10s，最大QPS为20的配置下，WarmUpController会把QPS逐步从6.66QPS在10s的时间内爬升到20QPS，相应的，RateLimiterController会将这个间隔从150ms逐步降低到50ms。
if (restToken >= warningToken) {
long aboveToken = restToken - warningToken;
// current interval = restToken*slope+1/count
double warmingQps = Math.nextUp(1.0 / (aboveToken * slope + 1.0 / count));
costTime = Math.round(1.0 * (acquireCount) / warmingQps * 1000);
} else {
costTime = Math.round(1.0 * (acquireCount) / count * 1000);
}
