曾經在一個大神的博客裏看到這樣一句話：在開發高併發系統時，有三把利器用來保護系統：緩存、降級和限流。那麼何爲限流呢？顧名思義，限流就是限制流量，就像你寬帶包了 1 個 G 的流量，用完了就沒了。經過限流，咱們能夠很好地控制系統的 qps，從而達到保護系統的目的。本篇文章將會介紹一下經常使用的限流算法以及他們各自的特色。 算法
背景
曾經在一個大神的博客裏看到這樣一句話：在開發高併發系統時，有三把利器用來保護系統：緩存、降級和限流。那麼何爲限流呢？顧名思義，限流就是限制流量，就像你寬帶包了1個G的流量，用完了就沒了。經過限流，咱們能夠很好地控制系統的qps，從而達到保護系統的目的。本篇文章將會介紹一下經常使用的限流算法以及他們各自的特色。緩存
算法介紹
計數器法
計數器法是限流算法裏最簡單也是最容易實現的一種算法。好比咱們規定，對於A接口來講，咱們1分鐘的訪問次數不能超過100個。那麼咱們能夠這麼作：在一開始的時候，咱們能夠設置一個計數器counter，每當一個請求過來的時候，counter就加1，若是counter的值大於100而且該請求與第一個請求的間隔時間還在1分鐘以內，那麼說明請求數過多；若是該請求與第一個請求的間隔時間大於1分鐘，且counter的值還在限流範圍內，那麼就重置counter，具體算法的示意圖以下：網絡
具體的僞代碼以下：併發
public class CounterDemo {
public long timeStamp = getNowTime();
public int reqCount = 0;
public final int limit = 100; // 時間窗口內最大請求數
public final long interval = 1000; // 時間窗口ms
public boolean grant() {
long now = getNowTime();
if (now < timeStamp + interval) { // 在時間窗口內
reqCount++; // 判斷當前時間窗口內是否超過最大請求控制數
return reqCount > limit;
} else {
timeStamp = now; // 超時後重置
reqCount = 1;
return true;
}
}
}
這個算法雖然簡單，可是有一個十分致命的問題，那就是臨界問題，咱們看下圖：高併發
從上圖中咱們能夠看到，假設有一個惡意用戶，他在0:59時，瞬間發送了100個請求，而且1:00又瞬間發送了100個請求，那麼其實這個用戶在1秒裏面，瞬間發送了200個請求。咱們剛纔規定的是1分鐘最多100個請求，也就是每秒鐘最多1.7個請求，用戶經過在時間窗口的重置節點處突發請求，能夠瞬間超過咱們的速率限制。用戶有可能經過算法的這個漏洞，瞬間壓垮咱們的應用。spa
聰明的朋友可能已經看出來了，剛纔的問題實際上是由於咱們統計的精度過低。那麼如何很好地處理這個問題呢？或者說，如何將臨界問題的影響下降呢？咱們能夠看下面的滑動窗口算法。3d
滑動窗口
滑動窗口，又稱rolling window。爲了解決這個問題，咱們引入了滑動窗口算法。若是學過TCP網絡協議的話，那麼必定對滑動窗口這個名詞不會陌生。下面這張圖，很好地解釋了滑動窗口算法：code
在上圖中，整個紅色的矩形框表示一個時間窗口，在咱們的例子中，一個時間窗口就是一分鐘。而後咱們將時間窗口進行劃分，好比圖中，咱們就將滑動窗口劃成了6格，因此每格表明的是10分鐘。每過10分鐘，咱們的時間窗口就會往右滑動一格。每個格子都有本身獨立的計數器counter，好比當一個請求在0:35秒的時候到達，那麼0:30~0:39對應的counter就會加1。blog
那麼滑動窗口怎麼解決剛纔的臨界問題的呢？咱們能夠看上圖，0:59到達的100個請求會落在灰色的格子中，而1:00到達的請求會落在橘黃色的格子中。當時間到達1:00時，咱們的窗口會往右移動一格，那麼此時時間窗口內的總請求數量一共是200個，超過了限定的100個，因此此時可以檢測出來觸發了限流。token
我再來回顧一下剛纔的計數器算法，咱們能夠發現，計數器算法其實就是滑動窗口算法。只是它沒有對時間窗口作進一步地劃分，因此只有1格。
因而可知，當滑動窗口的格子劃分的越多，那麼滑動窗口的滾動就越平滑，限流的統計就會越精確。
漏桶算法
漏桶算法，又稱leaky bucket。爲了理解漏桶算法，咱們看一下維基百科上的對於該算法的示意圖：
從圖中咱們能夠看到，整個算法其實十分簡單。首先，咱們有一個固定容量的桶，有水流進來，也有水流出去。對於流進來的水來講，咱們沒法預計一共有多少水會流進來，也沒法預計水流的速度。可是對於流出去的水來講，這個桶能夠固定水流出的速率。並且，當桶滿了以後，多餘的水將會溢出。
咱們將算法中的水換成實際應用中的請求，咱們能夠看到漏桶算法天生就限制了請求的速度。當使用了漏桶算法，咱們能夠保證接口會以一個常速速率來處理請求。因此漏桶算法天生不會出現臨界問題。具體的僞代碼實現以下：
public class LeakyDemo {
public long timeStamp = getNowTime();
public int capacity; // 桶的容量public int rate; // 水漏出的速度public int water; // 當前水量(當前累積請求數)public boolean grant() {
long now = getNowTime();
water = max(0, water - (now - timeStamp) * rate); // 先執行漏水，計算剩餘水量
timeStamp = now;
if ((water + 1) < capacity) { // 嘗試加水,而且水還未滿
water += 1;
return true;
}else { // 水滿，拒絕加水
return false;
}
}
}
令牌桶算法
令牌桶算法，又稱token bucket。爲了理解該算法，咱們再來看一下維基百科上對該算法的示意圖：
從圖中咱們能夠看到，令牌桶算法比漏桶算法稍顯複雜。首先，咱們有一個固定容量的桶，桶裏存放着令牌（token）。桶一開始是空的，token以一個固定的速率r往桶裏填充，直到達到桶的容量，多餘的令牌將會被丟棄。每當一個請求過來時，就會嘗試從桶裏移除一個令牌，若是沒有令牌的話，請求沒法經過。
具體的僞代碼實現以下：
public class TokenBucketDemo {
public long timeStamp = getNowTime();
public int capacity; // 桶的容量 public int rate; // 令牌放入速度 public int tokens; // 當前令牌數量 public boolean grant() {
long now = getNowTime(); // 先添加令牌
tokens = min(capacity, tokens + (now - timeStamp) * rate);
timeStamp = now;
if (tokens < 1) { // 若不到1個令牌,則拒絕
return false;
}else { // 還有令牌，領取令牌
tokens -= 1; return true;
}
}
}
相關變種
若仔細研究算法，咱們會發現咱們默認從桶裏移除令牌是不須要耗費時間的。若是給移除令牌設置一個延時時間，那麼實際上又採用了漏桶算法的思路。Google的guava庫下的SmoothWarmingUp類就採用了這個思路。
臨界問題
咱們再來考慮一下臨界問題的場景。在0:59秒的時候，因爲桶內積滿了100個token，因此這100個請求能夠瞬間經過。可是因爲token是以較低的速率填充的，因此在1:00的時候，桶內的token數量不可能達到100個，那麼此時不可能再有100個請求經過。因此令牌桶算法能夠很好地解決臨界問題。下圖比較了計數器（左）和令牌桶算法（右）在臨界點的速率變化。咱們能夠看到雖然令牌桶算法容許突發速率，可是下一個突發速率必需要等桶內有足夠的token後才能發生：
總結
計數器 VS 滑動窗口
計數器算法是最簡單的算法，能夠當作是滑動窗口的低精度實現。滑動窗口因爲須要存儲多份的計數器（每個格子存一份），因此滑動窗口在實現上須要更多的存儲空間。也就是說，若是滑動窗口的精度越高，須要的存儲空間就越大。
漏桶算法 VS 令牌桶算法
漏桶算法和令牌桶算法最明顯的區別是令牌桶算法容許流量必定程度的突發。由於默認的令牌桶算法，取走token是不須要耗費時間的，也就是說，假設桶內有100個token時，那麼能夠瞬間容許100個請求經過。
令牌桶算法因爲實現簡單，且容許某些流量的突發，對用戶友好，因此被業界採用地較多。固然咱們須要具體狀況具體分析，只有最合適的算法，沒有最優的算法