Sentinel限流之快速失敗和漏桶演算法
距離上次總結Sentinel的滑動視窗演算法已經有些時間了，原本想著一口氣將它的core模組全部總結完，但是中間一懶就又鬆懈下來了，這幾天在工作之餘又重新整理了一下，在這裡做一個學習總結。
上篇滑動視窗演算法總結連結：https://www.cnblogs.com/mrxiaobai-wen/p/14212637.html
今天主要總結了一下Sentinel的快速失敗和勻速排隊的漏桶演算法。因為它的WarmUpController和WarmUpRateLimiterController對應的令牌桶演算法的數學計算原理有一點點複雜，所以我準備在後面單獨用一篇來總結。所以今天涉及到的主要就是DefaultController和RateLimiterController。
限流策略入口
首先進入到FlowRuleUtil類中，方法generateRater就是對應策略的建立，邏輯比較簡單，程式碼如下：
private static TrafficShapingController generateRater(FlowRule rule) { if (rule.getGrade() == RuleConstant.FLOW_GRADE_QPS) { switch (rule.getControlBehavior()) { case RuleConstant.CONTROL_BEHAVIOR_WARM_UP: // WarmUp-令牌桶演算法 return new WarmUpController(rule.getCount(), rule.getWarmUpPeriodSec(), ColdFactorProperty.coldFactor); case RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER: // 排隊等待-漏桶演算法 return new RateLimiterController(rule.getMaxQueueingTimeMs(), rule.getCount()); case RuleConstant.CONTROL_BEHAVIOR_WARM_UP_RATE_LIMITER: // 預熱和勻速排隊結合 return new WarmUpRateLimiterController(rule.getCount(), rule.getWarmUpPeriodSec(), rule.getMaxQueueingTimeMs(), ColdFactorProperty.coldFactor); case RuleConstant.CONTROL_BEHAVIOR_DEFAULT: default: // Default mode or unknown mode: default traffic shaping controller (fast-reject). } } // 快速失敗 return new DefaultController(rule.getCount(), rule.getGrade()); }
快速失敗DefaultController
預設流控演算法程式碼如下：
@Override public boolean canPass(Node node, int acquireCount, boolean prioritized) { int curCount = avgUsedTokens(node); // 當前閾值 + acquireCount 是否大於規則設定的count，小於等於則表示符合閾值設定直接返回true if (curCount + acquireCount > count) { // 在大於的情況下，針對QPS的情況會對先進來的請求進行特殊處理 if (prioritized && grade == RuleConstant.FLOW_GRADE_QPS) { long currentTime; long waitInMs; currentTime = TimeUtil.currentTimeMillis(); // 如果策略是QPS，那麼對於優先請求嘗試去佔用下一個時間視窗中的令牌 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; }
先看一下涉及到的avgUsedTokens方法：
private int avgUsedTokens(Node node) {
if (node == null) {
return DEFAULT_AVG_USED_TOKENS;
}
// 獲取當前qps或者當前執行緒數
return grade == RuleConstant.FLOW_GRADE_THREAD ? node.curThreadNum() : (int)(node.passQps());
}
主要是獲取已使用的令牌數，如果設定的閾值型別為執行緒數，那麼返回當前統計節點中儲存的執行緒數，如果設定的閾值型別為QPS，那麼返回已經通過的QPS數。
然後回到上面的canPass方法，其主要邏輯就是在獲取到目前節點的統計資料後，將已佔用的令牌數與請求的令牌數相加，如果小於設定的閾值，那麼直接放行。
如果大於設定的閾值，那麼在閾值型別為QPS且允許優先處理先到的請求的情況下進行特殊處理，否則返回false不放行。
上面特殊處理就是：首先嚐試去佔用後面的時間視窗的令牌，獲取到等待時間，如果等待時間小於設定的最長等待時長，那麼就進行等待，當等待到指定時間後返回。否則直接返回false不放行。
由程式碼可以看出，在等待指定時長後，丟擲PriorityWaitException進行放行，對應實現的地方在StatisticSlot中，對應entry方法程式碼如下：
@Override
public void entry(Context context, ResourceWrapper resourceWrapper, DefaultNode node, int count,
boolean prioritized, Object... args) throws Throwable {
try {
// Do some checking.
fireEntry(context, resourceWrapper, node, count, prioritized, args);
// 說明：省略了執行通過的處理邏輯
} catch (PriorityWaitException ex) {
node.increaseThreadNum();
if (context.getCurEntry().getOriginNode() != null) {
context.getCurEntry().getOriginNode().increaseThreadNum();
}
if (resourceWrapper.getEntryType() == EntryType.IN) {
Constants.ENTRY_NODE.increaseThreadNum();
}
for (ProcessorSlotEntryCallback<DefaultNode> handler : StatisticSlotCallbackRegistry.getEntryCallbacks()) {
handler.onPass(context, resourceWrapper, node, count, args);
}
} catch (BlockException e) {
// 說明：省略了阻塞異常處理邏輯
throw e;
} catch (Throwable e) {
context.getCurEntry().setError(e);
throw e;
}
}
對這個方法去除了其它多餘程式碼，可以看出在PriorityWaitException異常捕捉的程式碼中沒有繼續丟擲，所以對該請求進行了放行。
勻速排隊-漏桶演算法RateLimiterController
對於漏桶演算法，首先在網上盜用一張圖如下：
圖片來源：https://blog.csdn.net/tianyaleixiaowu/article/details/74942405
其思路是：水流（請求）先進入到漏桶裡，漏桶以一定的速率勻速流出，當流入量過大的時候，多餘水流（請求）直接溢位，從而達到對系統容量的保護。
對應Sentinel使用漏桶演算法進行流量整形的效果就如下圖所示：
來看RateLimiterController的canPass方法：
@Override
public boolean canPass(Node node, int acquireCount, boolean prioritized) {
if (acquireCount <= 0) {
return true;
}
if (count <= 0) {
return false;
}
long currentTime = TimeUtil.currentTimeMillis();
// 計算此次令牌頒發所需要的時間，其中： (1.0 / count * 1000)代表每個令牌生成的耗時，然後乘以acquireCount得到此次所需令牌生成耗時
long costTime = Math.round(1.0 * (acquireCount) / count * 1000);
// 在上次通過時間的基礎上加上本次的耗時，得到期望通過的時間點
long expectedTime = costTime + latestPassedTime.get();
if (expectedTime <= currentTime) {
// 如果期望時間小於當前時間，那麼說明當前令牌充足，可以放行，同時將當前時間設定為上次通過時間
latestPassedTime.set(currentTime);
return true;
} else {
// 當期望時間大於當前時間，那麼說明令牌不夠，需要等待
long waitTime = costTime + latestPassedTime.get() - TimeUtil.currentTimeMillis();
if (waitTime > maxQueueingTimeMs) {
// 如果需要等待時間大於設定的最大等待時長，那麼直接丟棄，不用等待，下面同理
return false;
} else {
long oldTime = latestPassedTime.addAndGet(costTime);
try {
// 再次檢查等待時長
waitTime = oldTime - TimeUtil.currentTimeMillis();
if (waitTime > maxQueueingTimeMs) {
latestPassedTime.addAndGet(-costTime);
return false;
}
// in race condition waitTime may <= 0
if (waitTime > 0) {
Thread.sleep(waitTime);
}
return true;
} catch (InterruptedException e) {
}
}
}
return false;
}
Sentinel的令牌桶演算法和漏桶演算法都參考了Guava RateLimiter的設計。
上面的邏輯很清晰，其思路就是根據當前令牌請求數量acquireCount乘以令牌生成速率得到本次所需令牌的生成時間，然後加上上次通過時間得到一個本次請求的期望通過時間，如果期望通過時間小於當前時間那麼說明容量足夠直接通過，如果期望通過時間大於當前時間那麼說明系統容量不夠需要等待，然後結合設定的等待時間判斷是繼續等待還是直接放棄。
需要特別注意的是，勻速模式具有侷限性，它只支援1000以內的QPS。我們可以看對應的語句：
long costTime = Math.round(1.0 * (acquireCount) / count * 1000);
long expectedTime = costTime + latestPassedTime.get();
很容易得到如下結果，每種閾值對應的令牌生成時間(單位：毫秒)：
| count | costTime |
|---|---|
| 100 | 10 |
| 1000 | 1 |
| 2000 | 1 |
| 3000 | 0 |
所以當閾值count大於2000後，每個令牌生成的時間間隔計算為0，那麼後面的判斷就沒有意義了。所以Sentinel的勻速器只支援QPS在1000以內的請求。