前面兩篇文章分別介紹了Sentinel怎么用，QPS怎么計算，接下來介紹下Sentinel限流策略
Alibaba Sentinel限流功能
Alibaba Sentinel與滑動時間窗口

Sentinel限流策略接口定義在 TrafficShapingController中，核心方法canPass，實現(xiàn)是否將流量放行的邏輯。

public interface TrafficShapingController {
   
    boolean canPass(Node node, int acquireCount, boolean prioritized);

    boolean canPass(Node node, int acquireCount);
}

其有四種實現(xiàn)，分別是基于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.計算當前窗口計數(shù)之和
        int curCount = avgUsedTokens(node);
        //2.比較當前流量與規(guī)則限制
        if (curCount + acquireCount > count) {
            //3.即使超限，如果prioritized設為true，則認為是重要業(yè)務，可以嘗試讓業(yè)務線程sleep到下一個窗口，借用下一個窗口的計數(shù)
            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的策略，無論流量在一秒內(nèi)的某個ms單位時間點同時進來，還是均勻的每100ms進來一個請求，都是一視同仁的，都可以通過。使用RateLimiterControlle策略，則要求每一個請求，距離上一次請求通過的間隔，必須大于等于100ms，才可以放行，否則必須sleep一段時間，直到間隔大于等于100ms，否則拒絕?？梢哉J為這是一種基于固定頻率的限流機制。
見代碼

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已經(jīng)在1600ms，表名系統(tǒng)其實是閑著的，直接通過即可。
        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

部分業(yè)務系統(tǒng)，當啟動完畢，或者長期處于低負荷狀態(tài)運行時，會因為資源初始化（比如數(shù)據(jù)庫建立連接，遠程網(wǎng)絡連接）的問題，無法應對突如其來的大流量。WarmUpController提供的限流策略，支持系統(tǒng)在一個時間段，以一個曲線爬坡，逐步增加系統(tǒng)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();
        // 這種情況相當于冷狀態(tài)
        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 {// 這種情況相當于熱狀態(tài)

            if (passQps + acquireCount <= count) {
                return true;
            }
        }
        return false;
    }

這種策略將限流器模擬為token桶，QPS如果限制為20，則認為每秒自動往桶里加20個token，每通過一個請求，從桶里拿走一個token。

這種WarmUp策略的關鍵邏輯有兩個：
1.判斷系統(tǒng)怎么樣算冷狀態(tài)。
2.warmUp爬坡的坡度。

相關的公式見下。WarmUpController默認的coldFactor=3，如果定義冷啟動時間10s，最大QPS為20。則可以得出warningToken=100，maxToken= 200 slope = 0.001
通俗的講，在這種定義下，流量進來拿token的速度如果很慢，桶里剩余token大于等于100，則認為是冷狀態(tài)，走冷狀態(tài)的爬坡限流機制，會從6.66QPS在10s鐘的時間內(nèi)爬升到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版，也是以一個較低初始頻率，逐步爬坡到目標頻率。其實現(xiàn)類繼承自WarmUpController，各種指標計算公式完成復用的，只是把WarmUpController計算得出的qps轉換成頻率進行限流。比如冷啟動時間10s，最大QPS為20的配置下，WarmUpController會把QPS逐步從6.66QPS在10s的時間內(nèi)爬升到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);
        }