1. 程式人生 > >簡析限流演算法

簡析限流演算法

1.簡介

限流顧名思義是限制流量,限制流量的目的是為了保障服務穩定執行,避免服務被流量沖垮。當流量超出服務處理能力時,部分請求將會被限流元件攔截。被攔截的請求可能會被丟棄,如果是 C 端請求,那麼這個請求可能會被導向指定的錯誤頁上,而不是生硬的拒絕。這裡我們丟棄掉一部分請求,以保證大部分請求可以正常響應。如果我們不這樣做,那麼服務崩潰後,所有請求都將無法響應了。當一臺機器崩潰後,該機器的所有流量將由其他機器承擔,這樣就會造成剩餘機器壓力增大,進而導致奔潰,最後形成雪崩。除此之外,服務崩潰還會造成資料不一致的嚴重問題,特別是一些敏感資料。比如對於電商網站,如果後臺服務準備將某筆訂單資料存入資料庫時,服務突然崩潰,導致資料沒有落庫。這個時候,開發同學就要想辦法修訂資料了。

綜上,我們可以看出來限流的重要性。接下來,我將向大家介紹三種常用的限流演算法,分別是計數器、漏桶演算法和令牌桶演算法。下面我們從最簡單的計數器開始說起。

2.限流演算法

2.1 計數器

計數器演算法的思想很簡單,每當一個請求到來時,我們就將計數器加一,當計數器數值超過閾值後,就拒絕餘下請求。一秒鐘後,我們將計數器清零,開始新一輪的計數。計數器演算法簡單粗暴,易於實現。但是缺點也是有的,也就是所謂的"突刺現象"。舉例說明一下,假如我們給計數器設定的閾值為100。系統瞬間內(比如10毫秒內)有200個請求到來,這個時候計數器只能放過其中的100個請求,餘下的100個請求全部被拒絕掉。如果第二秒內沒有請求到來,那麼系統就處於空閒狀態。也就是上一秒忙的要死,這一秒又閒的要死。如果我們能用一個容器將剩餘的100個請求快取起來,待計數器重置後再將這些請求放出來。這樣系統在這兩秒內的吞吐量就由100變成了200,提升了一倍。基於這個思考,下面我們再來看看漏桶演算法。

2.2 漏桶演算法

漏桶演算法由流量容器、流量入口和出口組成。其中流量出口流速即為我們期望的限速值,比如 100 QPS。漏桶演算法除了具備限流能力,還具備流量整型功能。下面我們通過一張圖來了解漏桶演算法。

圖片來源:未知

如上圖,流入漏桶流量的流速是不恆定的,經過漏桶限速後,流出流量的速度是恆定的。需要說明的是,漏桶的容量是有限的,一旦流入流量超出漏桶容量,這部分流量只能被丟棄了。

漏桶是一個比較好的限流整型工具,不過漏桶不能處理突發流量,一些觀點認為這是它的一個缺點。不過如果較起真來,我覺得這個缺點是不成立的。畢竟漏桶本就是用來平滑流量的,如果支援突發,那麼輸出流量反而不平滑了。如果要找一種能夠支援突發流量的限流演算法,那麼令牌桶演算法可以滿足需求。

2.3 令牌桶演算法

令牌桶和漏桶頗有幾分相似,只不過令牌通裡存放的是令牌。它的執行過程是這樣的,一個令牌工廠按照設定值定期向令牌桶發放令牌。當令牌桶滿了後,多出的令牌會被丟棄掉。每當一個請求到來時,該請求對應的執行緒會從令牌桶中取令牌。初期由於令牌桶中存放了很多個令牌,因此允許多個請求同時取令牌。當桶中沒有令牌後,無法獲取到令牌的請求可以丟棄,或者重試。下面我們來看一下的令牌桶示意圖:

圖片來源:未知

儘管令牌桶允許突發流量,但突發流量速率 R1 + 限流速率 R2 不能超過系統最大的處理能力 Rt,即 R1 + R2 ≤ Rt,否則會沖垮系統。

3.總結

以上就是本篇文章的全部內容。本篇文章簡單分析幾種常見限流演算法的執行過程,限於能力原因,文章若有錯誤不妥之處還請指明。除了文字性描述,這裡也把三種演算法的簡單實現程式碼貼出來 RateLimiter,有興趣的同學自取。

好了,本篇文章到這裡就結束了,感謝大家的閱讀。

本文在知識共享許可協議 4.0 下發布,轉載需在明顯位置處註明出處
作者:田小波
本文同步釋出在我的個人部落格:http://www.tianxiaobo.com


本作品採用知識共享署名-非商業性使用-禁止演繹 4.0 國際許可協議進行許可