接口限流的經常使用算法彙總

時間 2019-11-07

標籤接口限流經常使用算法彙總简体版

原文原文鏈接

接口限流

什麼是接口限流算法

那麼什麼是限流呢？顧名思義，限流就是限制流量，包括併發的流量和必定時間內的總流量，就像你寬帶包了1個G的流量，用完了就沒了，因此控制你的使用頻率和單次使用的總消耗。經過限流，咱們能夠很好地控制系統的qps，從而達到保護系統或者接口服務器穩定的目的。服務器

接口限流的經常使用算法併發

計數器法this

計數器法是限流算法裏最簡單也是最容易實現的一種算法。好比咱們規定，對於A接口來講，咱們1分鐘的訪問次數不能超過100個。那麼咱們能夠這麼作：在一開始的時候，咱們能夠設置一個計數器counter，每當一個請求過來的時候，counter就加1，若是counter的值大於100而且該請求與第一個請求的間隔時間還在1分鐘以內，那麼說明請求數過多；若是該請求與第一個請求的間隔時間大於1分鐘，且counter的值還在限流範圍內，那麼就重置 counter，具體算法的示意圖以下：spa

僞代碼以下code

class CounterDemo{

    private  $timeStamp;
    public  $reqCount=0;
    public  $limit=100;//時間窗口內最大請求數
    public $interval=1000; //時間窗口 ms


    public function __construct()
    {
        $this->timeStamp = time();
    }
    public  function grant(){
        $now=time();
        if($now<$this->timeStamp+$this->interval){
            //時間窗口內
            $this->reqCount++;
            return $this->reqCount<=$this->limit;
        }else{
            // 超時後重置
            $this->timeStamp=time();
            $this->reqCount=1;
            return true;
        }

    }

}

這個算法看起來簡單可是有個很嚴重的問題,那就是臨界問題，看下圖blog

從上圖中咱們能夠看到，假設有一個惡意用戶，他在0:59時，瞬間發送了100個請求，而且1:00又瞬間發送了100個請求，那麼其實這個用戶在 1秒裏面，瞬間發送了200個請求。咱們剛纔規定的是1分鐘最多100個請求，也就是每秒鐘最多1.7個請求，用戶經過在時間窗口的重置節點處突發請求，能夠瞬間超過咱們的速率限制。用戶有可能經過算法的這個漏洞，瞬間壓垮咱們的應用。token

聰明的朋友可能已經看出來了，剛纔的問題實際上是由於咱們統計的精度過低。那麼如何很好地處理這個問題呢？或者說，如何將臨界問題的影響下降呢？咱們能夠看下面的滑動窗口算法。接口

滑動窗口算法
直接上圖吧圖片

在上圖中，整個紅色的矩形框表示一個時間窗口，在咱們的例子中，一個時間窗口就是一分鐘。而後咱們將時間窗口進行劃分，好比圖中，咱們就將滑動窗口劃成了6格，因此每格表明的是10秒鐘。每過10秒鐘，咱們的時間窗口就會往右滑動一格。每個格子都有本身獨立的計數器counter，好比當一個請求在0:35秒的時候到達，那麼0:30~0:39對應的counter就會加1。

那麼滑動窗口怎麼解決剛纔的臨界問題的呢？咱們能夠看上圖，0:59到達的100個請求會落在灰色的格子中，而1:00到達的請求會落在橘黃色的格子中。當時間到達1:00時，咱們的窗口會往右移動一格，那麼此時時間窗口內的總請求數量一共是200個，超過了限定的100個，因此此時可以檢測出來觸發了限流。

我再來回顧一下剛纔的計數器算法，咱們能夠發現，計數器算法其實就是滑動窗口算法。只是它沒有對時間窗口作進一步地劃分，因此只有1格。
因而可知，當滑動窗口的格子劃分的越多，那麼滑動窗口的滾動就越平滑，限流的統計就會越精確。

漏桶算法
漏桶算法，又稱leaky bucket。爲了理解漏桶算法，咱們看一下維基百科上的對於該算法的示意圖：

從圖中咱們能夠看到，整個算法其實十分簡單。首先，咱們有一個固定容量的桶，有水流進來，也有水流出去。對於流進來的水來講，咱們沒法預計一共有多少水會流進來，也沒法預計水流的速度。可是對於流出去的水來講，這個桶能夠固定水流出的速率。並且，當桶滿了以後，多餘的水將會溢出。

咱們將算法中的水換成實際應用中的請求，咱們能夠看到漏桶算法天生就限制了請求的速度。當使用了漏桶算法，咱們能夠保證接口會以一個常速速率來處理請求。因此漏桶算法天生不會出現臨界問題。具體的僞代碼實現以下：

class LeakyDemo{

    private  $timeStamp;
    public  $capacity;// 桶的容量
    public  $rate; // 水漏出的速度
    public  $water;// 當前水量(當前累積請求數)


    public function __construct()
    {
        $this->timeStamp = time();
    }
    public  function grant(){
        $now=time();
        $this->water=max(0,$this->water-($now-$this->timeStamp)*$this->rate);// 先執行漏水，計算剩餘水量
        $this->timeStamp=$now;
        if(($this->water+1)<$this->capacity){
            // 嘗試加水,而且水還未滿
            $this->water+=1;
            return true;
        }else{
            // 水滿，拒絕加水
            return false;
        }

    }

}

令牌桶算法
令牌桶算法，又稱token bucket。爲了理解該算法，咱們再來看一下維基百科上對該算法的示意圖：

從圖中咱們能夠看到，令牌桶算法比漏桶算法稍顯複雜。首先，咱們有一個固定容量的桶，桶裏存放着令牌（token）。桶一開始是空的，token以一個固定的速率r往桶裏填充，直到達到桶的容量，多餘的令牌將會被丟棄。每當一個請求過來時，就會嘗試從桶裏移除一個令牌，若是沒有令牌的話，請求沒法通過。

具體的僞代碼實現以下：

class TokenBucketDemo{
    private  $timeStamp;
    public  $capacity;// 桶的容量
    public  $rate; // 令牌放入的速度
    public  $tokens;// 當前令牌的數量


    public function __construct()
    {
        $this->timeStamp = time();
    }
    public  function grant(){
        $now=time();
        $this->tokens=min(0,$this->tokens+($now-$this->timeStamp)*$this->rate);// 先執行漏水，計算剩餘水量
        $this->timeStamp=$now;
        if($this->tokens<1){
            // 若不到1個令牌,則拒絕
            return false;
        }else{
            // 還有令牌，領取令牌
            $this->tokens -= 1;
            return true;
        }

    }

}

臨界問題
臨界問題

咱們再來考慮一下臨界問題的場景。在0:59秒的時候，因爲桶內積滿了100個token，因此這100個請求能夠瞬間經過。可是因爲token是以較低的速率填充的，因此在1:00的時候，桶內的token數量不可能達到100個，那麼此時不可能再有100個請求經過。因此令牌桶算法能夠很好地解決臨界問題。下圖比較了計數器（左）和令牌桶算法（右）在臨界點的速率變化。咱們能夠看到雖然令牌桶算法容許突發速率，可是下一個突發速率必需要等桶內有足夠的 token後才能發生