Set up a Redis backplane for Rate Limiting ASP.NET Core multi-node deployments. The library is build on top of the built-in Rate Limiting support that's part of .NET 7.
For more advanced use cases you can check out the official documentation here.
PM> Install-Package RedisRateLimiting
TargetFramework: net7.0
Dependencies:
StackExchange.Redis (>= 2.6.86)
System.Threading.RateLimiting (>= 7.0.0)
PM> Install-Package RedisRateLimiting.AspNetCore
TargetFramework: net7.0
Dependencies:
RedisRateLimiting (>= 1.0.7)
Concurrency Rate Limiter limits how many concurrent requests can access a resource. If your limit is 10, then 10 requests can access a resource at once and the 11th request will not be allowed. Once the first request completes, the number of allowed requests increases to 1, when the second request completes, the number increases to 2, etc.
Instead of "You can use our API 1000 times per second", this rate limiting strategy says "You can only have 20 API requests in progress at the same time".
You can use a new instance of the RedisConcurrencyRateLimiter class or configure the predefined extension method:
builder.Services.AddRateLimiter(options =>
{
options.AddRedisConcurrencyLimiter("demo_concurrency", (opt) =>
{
opt.ConnectionMultiplexerFactory = () => connectionMultiplexer;
opt.PermitLimit = 5;
// Queue requests when the limit is reached
//opt.QueueLimit = 5
});
});
The Fixed Window algorithm uses the concept of a window. The window is the amount of time that our limit is applied before we move on to the next window. In the Fixed Window strategy, moving to the next window means resetting the limit back to its starting point.
You can use a new instance of the RedisFixedWindowRateLimiter class or configure the predefined extension method:
builder.Services.AddRateLimiter(options =>
{
options.AddRedisFixedWindowLimiter("demo_fixed_window", (opt) =>
{
opt.ConnectionMultiplexerFactory = () => connectionMultiplexer;
opt.PermitLimit = 1;
opt.Window = TimeSpan.FromSeconds(2);
});
});
Unlike the Fixed Window Rate Limiter, which groups the requests into a bucket based on a very definitive time window, the Sliding Window Rate Limiter, restricts requests relative to the current request's timestamp. For example, if you have a 10 req/minute rate limiter, on a fixed window, you could encounter a case where the rate-limiter allows 20 requests during a one minute interval. This can happen if the first 10 requests are on the left side of the current window, and the next 10 requests are on the right side of the window, both having enough space in their respective buckets to be allowed through. If you send those same 20 requests through a Sliding Window Rate Limiter, if they are all sent during a one minute window, only 10 will make it through.
You can use a new instance of the RedisSlidingWindowRateLimiter class or configure the predefined extension method:
builder.Services.AddRateLimiter(options =>
{
options.AddRedisSlidingWindowLimiter("demo_sliding_window", (opt) =>
{
opt.ConnectionMultiplexerFactory = () => connectionMultiplexer;
opt.PermitLimit = 1;
opt.Window = TimeSpan.FromSeconds(2);
});
});
Token Bucket is an algorithm that derives its name from describing how it works. Imagine there is a bucket filled to the brim with tokens. When a request comes in, it takes a token and keeps it forever. After some consistent period of time, someone adds a pre-determined number of tokens back to the bucket, never adding more than the bucket can hold. If the bucket is empty, when a request comes in, the request is denied access to the resource.
You can use a new instance of the RedisTokenBucketRateLimiter class or configure the predefined extension method:
builder.Services.AddRateLimiter(options =>
{
options.AddRedisTokenBucketLimiter("demo_token_bucket", (opt) =>
{
opt.ConnectionMultiplexerFactory = () => connectionMultiplexer;
opt.TokenLimit = 2;
opt.TokensPerPeriod = 1;
opt.ReplenishmentPeriod = TimeSpan.FromSeconds(2);
});
});
These samples intentionally keep things simple for clarity.