限流演算法之漏桶演算法令牌桶演算法

每個api介面都是有訪問上限的，當訪問頻率或者併發量超過其承受範圍時候，我們就必須考慮限流來保證介面的可用性或者降級可用性。即介面也需要安裝上保險絲,以防止非預期的請求對系統壓力過大而引起的系統癱瘓。

通常的策略就是拒絕多餘的訪問，或者讓多餘的訪問排隊等待服務，或者引流。

如果要準確的控制qps，簡單的做法是維護乙個單位時間內的counter，如判斷單位時間已經過去，則將counter重置零。此做法被認為沒有很好的處理單位時間的邊界，比如在前一秒的最後一毫秒裡和下一秒的第一毫秒都觸發了最大的請求數，將目光移動一下，就看到在兩毫秒內發生了兩倍的qps。

常用的更平滑的限流演算法有兩種：漏桶演算法和令牌桶演算法。

漏桶(leaky bucket)演算法思路很簡單，水(請求)先進入到漏桶裡，漏桶以一定的速度出水(介面有響應速率)，當水流入速度過大會直接溢位(訪問頻率超過介面響應速率)，然後就拒絕請求，可以看出漏桶演算法能強行限制資料的傳輸速率。示意圖如下:

可見這裡有兩個變數，乙個是桶的大小，支援流量突發增多時可以存多少的水(burst)，另乙個是水桶漏洞的大小(rate)。

因為漏桶的漏出速率是固定的引數，所以，即使網路中不存在資源衝突(沒有發生擁塞)，漏桶演算法也不能使流突發(burst)到埠速率。因此，漏桶演算法對於存在突發特性的流量來說缺乏效率。

令牌桶演算法(token bucket)和 leaky bucket 效果一樣但方向相反的演算法，更加容易理解。

隨著時間流逝，系統會按恆定1/qps時間間隔(如果qps=100,則間隔是10ms)往桶裡加入token(想象和漏洞漏水相反，有個水龍頭在不斷的加水)，如果桶已經滿了就不再加了。新請求來臨時，會各自拿走乙個token，如果沒有token可拿了就阻塞或者拒絕服務。

令牌桶的另外乙個好處是可以方便的改變速度。一旦需要提高速率，則按需提高放入桶中的令牌的速率。一般會定時(比如100毫秒)往桶中增加一定數量的令牌，有些變種演算法則實時的計算應該增加的令牌的數量。

限流演算法之漏桶演算法 令牌桶演算法