您好，登录后才能下订单哦！
密码登录
登录注册
点击 登录注册 即表示同意《亿速云用户服务条款》
本篇内容主要讲解“ASP.NET Core中使用滑动窗口限流的问题举例分析”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“ASP.NET Core中使用滑动窗口限流的问题举例分析”吧!
滑动窗口算法用于应对请求在时间周期中分布不均匀的情况，能够更精确的应对流量变化，比较著名的应用场景就是TCP协议的流量控制，不过今天要说的是服务限流场景中的应用。
这里假设业务需要每秒钟限流100次，先来看固定窗口算法的两个问题：
如下图所示，单看第1秒和第2秒，其请求次数都没有超过100，所以使用固定窗口算法时不会触发限流。但是第1秒的后500ms的请求数加上第2秒的前500毫秒的请求数就超过了100，这时候可能会给系统带来伤害，使用固定窗口算法时不能检测到这种情况。
针对漏检的问题，你可能会说，可以把时间窗口设置为500ms，把限流阈值设置为50。那么来看下图，除了第2个计数周期超过了50，从而触发限流，前后几个计数周期的请求都很正常，甚至都不会超过阈值的50%，可能第2个计数周期的情况实在太特殊，1天都不会出现第2次，如果对系统不会造成影响，能不能通融下，做不到！固定窗口算法这时候就会显得太过刚性。
那么滑动窗口如何来解决这两个问题呢？还是先来看图：
如上图所示：
滑动窗口的时间跨度是1秒，每个小计数周期的时间跨度是500ms，此处的滑动窗口包含2个小计数周期。
随着时间的前进，滑动窗口包含的小计数周期会以500ms为单位向前移动，但始终是包含2个小计数周期。
判断是否限流时，需要将当前滑动窗口包含的2个小计数周期的计数值加起来。
相比固定窗口计数器算法，滑动窗口可以有效减少漏检，如上图滑动窗口移动到了500-1500ms，发现总数超过100，则触发限流；滑动窗口在0-1000ms、1000-2000ms时都不会触发限流，即使其中某个小周期的计数值超过了阈值的半数，但是总数没有超过100，就不会限流，能够应对极少出现的突发流量情况。
从分析还可以看出，滑动窗口的小周期划分的越多，则检测越准确，但用于跟踪的计数也越多，使用的内存和计算量都会增大。
这里讲两种实现方法：进程内即内存滑动窗口算法、基于Redis的滑动窗口算法。
这里介绍一种性能比较高的方法，使用数组实现滑动窗口，这是环形队列的一种特例，如下图所示：
假设滑动窗口需要5个小的计数周期，则初始化一个长度为5的整形数组，数字表示数组中的第几个元素。
我们知道队列有头有尾，从队头取出数据，向队尾插入数据，带括号的数字表示是队列中的第几个元素。
滑动窗口向前移动时，队尾向右移动1位，同时队头也向右移动1位。
队尾和队头向右移动都可能会溢出数组，此时让它们回到数组的起始位置，即图中数组的第1个位置。
关于这个算法的详细介绍，可以看这篇文章：如何使用数组实现滑动窗口
基于Redis时也可以使用类似环形队列的方法，比如定义5个KV作为数组的5个元素。不过我之前实现时采用了一种更直观的方式，每个小的计数周期都创建一个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 InProcessSlidingWindowAlgorithm(
new[] {
// 构造函数有两个参数：滑动窗口的时间长度、小计数周期的时间长度
new SlidingWindowRule(TimeSpan.FromSeconds(5), TimeSpan.FromSeconds(1))
{
ExtractTarget = context =>
{
// 提取限流目标
return (context as HttpContext).Request.Path.Value;
},
CheckRuleMatching = context =>
{
// 判断当前请求是否需要限流处理
return true;
},
Name="sliding window limit rule",
LimitNumber=100, // 限流阈值，这里即5秒最多100次请求
}
})
);
...
}
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
...
app.UseRateLimit();
...
}如上需要先注册服务，然后使用中间件。
注册服务的时候需要提供限流算法和对应的规则：
这里使用进程内固定窗口算法InProcessSlidingWindowAlgorithm，还可以使用RedisSlidingWindowAlgorithm，需要传入一个Redis连接。两种算法都支持同步和异步方法。
限流阈值是100，限流滑动窗口是5秒，小计数周期是1秒。
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进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。