溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹了如何解決ASP.NET Core中使用漏桶算法限流的問題，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。
漏桶算法是限流的四大主流算法之一，其應用場景各種資料中介紹的不多，一般都是說應用在網絡流量控制中。這里舉兩個例子：
1、目前家庭上網都會限制一個固定的帶寬，比如100M、200M等，一棟樓有很多的用戶，那么運營商怎么保證某些用戶沒有使用過多的帶寬，從而影響到別人呢？這時就可以使用漏桶算法，限制每個用戶訪問網絡的最大帶寬，當然實際會比這復雜很多。
2、有一個祖傳接口，當時寫的時候沒有任何保護措施，現在訪問量稍微大點就會崩潰，但是代碼誰也改不動。這時候也可以用漏桶算法，把這個接口封裝一下，將外部請求通過漏桶算法進行整流，再轉發給這個接口，此時訪問頻率不會超過閾值，接口就不會崩潰了。
說了這么多，那漏桶算法到底是怎么解決問題的呢？請看下圖。
接收到請求后，先把請求放到一個漏桶中，漏桶以恒定的速率漏出請求，然后漏出的請求被處理；如果接收請求的速度過快，導致漏桶滿了，則丟棄新的請求。
可以看出，漏桶算法主要是通過恒速的方式輸出，給后續數據處理一個穩定的輸入。這樣它就能應對一定的突發流量，使系統不會因為請求量突增而導致崩潰，只不過是通過增加延遲的方式，會有那么一點浪費資源，這和令牌桶的處理方式不同，關于令牌桶算法可以看這篇文章：ASP.NET Core中使用令牌桶限流。
還有一個不常提及的好處，恒速的輸出有時候也可以提升效率，比如一次允許漏出兩個請求，則可以將兩次處理合并為一次處理，如果每次處理都涉及到網絡IO，則合并處理就有機會減少網絡IO的開銷。
這里講兩種實現方法：進程內即內存漏桶算法、基于Redis的漏桶算法。
這里在請求時計算漏出數量，沒有單獨的漏出處理，描述的算法稍顯復雜，不過只需要增加一點耐心，也很容易理解。
先來定義幾個變量：
對于漏出速率，用 [每X時間周期Y個] 來表示。X時間周期一般是若干秒、分鐘、小時等時間跨度。
對于當前時間周期的開始時間用Ts表示，當前時間周期的結束時間用Te表示，當前時間用Ti表示。
對于漏桶容量，用Z來表示。
對于X時間內的所有請求數量，用N來表示。
當請求到達時，則可以按以下次序處理：
如果Ti-Ts<=X，說明還在當前時間周期內，先增加N的值：
比較N和Y，如果N<=Y，則請求無需等待，直接漏出，進入處理階段；
如果N>Y，則比較N與Y+Z：
如果N<=Y+Z，則請求進入漏桶等待，等待時間為：(math.ceiling((N-Y)/Y)-1)*X+(Te - Ti)，等待結束后漏出，進入處理階段；
如果N>Y+Z，則請求無法進入漏桶，只能丟棄掉，實現上就是拒絕請求；
如果Ti-Ts>X，則需要創建新的時間周期：
計算過去了幾個時間周期：Pn=math.ceiling((Ti-Te)/X)；
重設Ts和Te的值：Ts=上次的Ts+Pn*X，Te=Ts+X；
計算這段時間最大可以漏出的數量：Yo=Pn*Y；
計算N的值：N= N-Yo<=0 ? 0: N-Yo；
此時符合Ti-Ts<=X，又在當前時間周期內了，再回到上邊的步驟依次處理。
基于Redis也可以實現上述的算法，只不過變量的表示方式換成了Redis KV，算法邏輯還是一樣的。
這些操作邏輯可以封裝在一個Lua script中，因為Lua script在Redis中執行時也是原子操作，所以Redis的限流計數在分布式部署時天然就是準確的。
雖然業務服務中不怎么常用，這里還是以限流組件 FireflySoft.RateLimit 為例，實現ASP.NET Core中的漏桶算法限流。
有多種安裝方式，選擇自己喜歡的就行了。
包管理器命令：
Install-Package FireflySoft.RateLimit.AspNetCore
或者.NET命令:
dotnet add package FireflySoft.RateLimit.AspNetCore
或者項目文件直接添加：
<ItemGroup> <PackageReference Include="FireflySoft.RateLimit.AspNetCore" Version="2.*" /> </ItemGroup>
在Startup中使用中間件，演示代碼如下（下邊會有詳細說明）：
public void ConfigureServices(IServiceCollection services)
{
...
app.AddRateLimit(new InProcessLeakyBucketAlgorithm(
new[] {
// 三個參數：漏桶的容量、單位時間漏出的數量、漏出的單位時間
new LeakyBucketRule(20,10, TimeSpan.FromSeconds(1))
{
ExtractTarget = context =>
{
// 提取限流目標
return (context as HttpContext).Request.Path.Value;
},
CheckRuleMatching = context =>
{
// 判斷當前請求是否需要限流處理
return true;
},
Name="leaky bucket limit rule",
}
})
);
...
}
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
...
app.UseRateLimit();
...
}如上需要先注冊服務，然后使用中間件。
注冊服務的時候需要提供限流算法和對應的規則：
這里使用進程內漏桶算法InProcessLeakyBucketAlgorithm，還可以使用RedisLeakyBucketAlgorithm，需要傳入一個Redis連接。兩種算法都支持同步和異步方法。
漏桶的容量是20，單位時間漏出的數量10，漏出的單位時間是1秒。也就是說1秒漏出10個，1秒內超出10個請求就會被延遲處理，加上漏桶的容量，1秒內超出30個請求就會被限流。
ExtractTarget用于提取限流目標，這里是每個不同的請求Path，可以根據需求從當前請求中提取關鍵數據，然后設定各種限流目標。如果有IO請求，這里還支持對應的異步方法ExtractTargetAsync。
CheckRuleMatching用于驗證當前請求是否限流，傳入的對象也是當前請求，方便提取關鍵數據進行驗證。如果有IO請求，這里還支持對應的異步方法CheckRuleMatchingAsync。
默認被限流時會返回HttpStatusCode 429，可以在AddRateLimit時使用可選參數error自定義這個值，以及Http Header和Body中的內容。
基本的使用就是上邊例子中的這些了。
如果還是基于傳統的.NET Framework，則需要在Application_Start中注冊一個消息處理器RateLimitHandler，算法和規則部分都是共用的，具體可以看Github上的使用說明：https://github.com/bosima/FireflySoft.RateLimit
FireflySoft.RateLimit 是一個基于 .NET Standard 的限流類庫，其內核簡單輕巧，能夠靈活應對各種需求的限流場景。
其主要特點包括：
多種限流算法：內置固定窗口、滑動窗口、漏桶、令牌桶四種算法，還可自定義擴展。
多種計數存儲：目前支持內存、Redis兩種存儲方式。
分布式友好：通過Redis存儲支持分布式程序統一計數。
限流目標靈活：可以從請求中提取各種數據用于設置限流目標。
支持限流懲罰：可以在客戶端觸發限流后鎖定一段時間不允許其訪問。
動態更改規則：支持程序運行時動態更改限流規則。
自定義錯誤：可以自定義觸發限流后的錯誤碼和錯誤消息。
普適性：原則上可以滿足任何需要限流的場景。
感謝你能夠認真閱讀完這篇文章，希望小編分享的“如何解決ASP.NET Core中使用漏桶算法限流的問題”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
