大家好，今天跟大家聊聊後台的限流技術，如有不對，歡迎指正哦！

　　什麼是限流 我們先來看看維基百科的定義：

　　通俗點講，限流就是流量限制，可以用來管控請求的速度。那為什麼需要管控請求速度呢？來看以下一個場景：

　　自己開發過一個網站，為了方便存儲網站的數據，買了一個四核的數據庫，算下來網站每秒能處理的請求也就幾千量級。如果這時候網站訪問過于火爆，湧進來一波流量，這波流量以每秒10w的頻率訪問業務，然後直接打到數據庫，那麼數據庫可能會不堪重負，直接被壓垮了。

　　所以不管是什麼後台服務，每秒能處理的請求個數總有極限。如果超過這個極限，輕則讓服務變得緩慢，重則直接幹跨業務，因此我們需要使用一些手段限制請求的發送頻率。一般來說，我們可以限制總的頻率，也可以更精細一點，比如針對用戶、IP等維度進行配額分發，思路都是相同的。

　　下面，就來給大家介紹下幾種不同的限頻算法，他們各有特色和優點，掌握他們就可以應對各個不同的場景。

　　計數器算法 顧名思義，計數器算法就是通過計數來記錄請求次數。先設定一個阈值，要求單位時間内的請求不得超過這個阈值。比如我們把單位時間内的阈值定為1000，每來一個請求，就計數 1，達到1000就拒絕訪問。等到過了單位時間，再重新計數。

　　在具體實現中，如果是單機限流，可以用一個整數 時間戳記錄。時間戳達到上限，則從0開始，計數達到阈值則拒絕。

　　分布式限流的話，一般使用Redis來做，可以利用 Redis 天然的過期時間，到了設定時間就自動過期。同時，記得要使用 LUA 腳本來保證 redis 的原子操作。

　　計數器算法的優點在于實現簡單，不易出錯。缺點：有請求突刺，可能會超過我們單位時間的阈值。

　　比如我們希望一段時間的請求數最多是2000，時間窗口是t1開始，到t2結束，然後是t2開始，到t3結束，那先在t2前一瞬間發送1000的請求，t2後一瞬間又立即發1000個請求，那麼在t1-t2，t2-t3這兩個時間窗口中，雖然都滿足了每分鐘不超過1000這個規則，但實際上在t2前後，這一分鐘的請求已達2000。

　　滑動窗口算法 滑動窗口算法，實際是計數器算法的優化版本。

　　計數器算法上面所說的突刺問題，本質是什麼？是我們将一段時間看成一個整體，而不是以基于物理時間來看時間窗口，這就導緻有漏洞可循。

　　那麼對症下藥，我們以當前物理時間為基點往前看，看基于當前時間的時間窗口，是否超過阈值，超過阈值就拒絕請求，問題就迎刃而解了。

　　我們相當于是将一個時間窗口，分為多個格子，比如20s一個格子，那我們一分鐘的時間窗口，就被分為了三個格子。每次基于當前時間，往前看三個格子，就是當前的滑動請求量。

　　有點抽象是不是，以時間粒度1小時舉個例子：

　　如果是普通窗口，時間區間就是1:00-2:00, 2:00-3:00這樣。如果有人在2:00前後搞事情，那就會造成突刺，突破上限。

　　而滑動窗口始終是基于當前，如果現在是2:00，那窗口就是1:00-2:00，如果是2:15，窗口就是1:15-2:15。

　　如果你在2點前幾乎怼滿了一波，那你必須得等當前時間滑得夠遠，你才怼第二波，這就解決了突刺。

　　說到這裡，大家可能要提一個問題，是不是計數器算法足夠小，也能解決突刺的問題？既然如此，滑動窗口還有意義麼？

　　其實仔細想一下，滑動的本質是基于當前的物理時間看窗口請求量，足夠小隻是粒度問題，滑動窗口同樣可以把粒度調小，但無論多小，滑動窗口都可以解決計數器算法解決不了的突刺超額問題。

　　小羊認為，滑動窗口就是計數器的完善版本。而計數器算法在突刺情況下，并沒有滿足 “單位時間内的請求數量不超過某個值” 的需求。

　　而從複雜度來講，滑動窗口雖說比技術器難一些，但也就100步和50步，一個量級。所以，如果實際開發中在計數器和滑動窗口上選型，那麼不用猶豫，選滑動窗口吧。

　　漏桶算法 前面介紹的是計數類算法，下面開始給大家介紹 Traffic Shaping 類的解決方式，我們先來看漏桶算法：

　　我們有一個桶，入水速度不定，出水速度由于管口較小，都是一滴一滴下來，所以速度恒定。如果桶滿了，我們就不能再往裡面加水了。

　　可以看到，入口流量頻率不變，出口速率始終恒定，我們利用這個特性，就可以做到均勻限頻。

　　但是漏桶算法也有一個明顯的缺點，我們無法精确判斷網絡帶寬或處理能力。一般來說都隻能設置一個相對比較小的流量目标，比如800/s。如果産生了一波突發流量，經過了漏桶算法後，依然會以恒定的目标碼率慢慢地發送。就算我們的服務有足夠的實力，也不能讓它快速處理了。所以說，漏桶算法無法充分用滿性能資源。

　　那怎麼解決呢？有兩種方式：

　　動态調節水滴速度（就像輸液瓶一樣）：通過對後端進行不斷試探，盡可能始終維持在性能處理的極緻，這種方式的弊端在于帶來了更多的複雜性和耦合性，屬于特定優化了。 2. 用另一種桶，令牌桶。

　　令牌桶算法 令牌桶算法是這樣的：我們有一個桶，桶裡均勻産生令牌，如果令牌把桶塞滿了，就不會再生産令牌。請求過來的時候，需要先拿到桶裡的令牌，才能做後續處理，如果桶裡沒有令牌了，可以選擇放棄或等待。

　　舉個例子：

　　我們桶裡面能放1000個令牌，1ms産生一個令牌，那1s就可以裝滿這個桶，請求要處理，先從桶裡拿令牌，這樣1s就能處理1000次，令牌桶算法很像生産消費模式，同時出口流量也很穩定。

　　令牌桶算法能夠在請求量小的時候，積累令牌，這種模式在限制數據的平均傳輸速率的同時還允許某種程度的突發傳輸。

　　四種算法對比 大家可能會說，這麼多算法，到底用哪種好的，别急，這就來比較下他們的優缺點。我們分别從複雜性、均勻度和容忍突發流量幾個維度來看：

　　複雜性：令牌桶 = 漏桶 滑動窗口 計數器，但實際上限流算法都不複雜，并且都有現成的實現，生産時候還是以實際需求為主，複雜性不用考慮太多。

　　均勻度：令牌桶和漏桶，其實都屬于流量整形算法，流量整形是說指不管流量到達的速率多麼不穩定，在接收流量後，都可以将其勻速輸出。而滑動窗口算法，計數器算法，隻是限制了一段時間的個數，沒有流量整形的效率，均勻度會低一些。

　　容忍突發流量：指的是限流策略允許流量在短時間内突增，且在突增結束後不會影響後續流量的正常限流，這一塊的話隻有令牌桶支持。

　　而唯一可以和令牌桶 battle 的漏桶，漏桶沒有針對突發流量的處理，嚴格限制，個人感覺這不是缺陷而是特性，并不是每個場景，都需要支持突發流量的，如果要很嚴格限定流量，漏桶會是最好的選擇。

　　至于計數器和滑動窗口算法，優勢就是簡單，但限流算法實際都不複雜，所以這個優勢就很不明顯了，生産上不建議使用。

　　限流是開發領域一個非常重要的話題，畢竟流控做好了，才不容易過載，才能有個穩定的系統，嘻嘻，希望大家看了文章有所收獲呀~

　　原文：htt

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!