前面两篇文章分别介绍了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);
        }