ASP.NET Core中使用滑动窗口限流

滑动窗口算法用于应对请求在时间周期中分布不均匀的情况,能够更精确的应对流量变化,比较著名的应用场景就是TCP协议的流量控制,不过今天要说的是服务限流场景中的应用。

算法原理

这里假设业务需要每秒钟限流100次,先来看固定窗口算法的两个问题:

  • 漏检

如下图所示,单看第1秒和第2秒,其请求次数都没有超过100,所以使用固定窗口算法时不会触发限流。但是第1秒的后500ms的请求数加上第2秒的前500毫秒的请求数就超过了100,这时候可能会给系统带来伤害,使用固定窗口算法时不能检测到这种情况。

ASP.NET Core中使用滑动窗口限流_第1张图片

  • 太刚

针对漏检的问题,你可能会说,可以把时间窗口设置为500ms,把限流阈值设置为50。那么来看下图,除了第2个计数周期超过了50,从而触发限流,前后几个计数周期的请求都很正常,甚至都不会超过阈值的50%,可能第2个计数周期的情况实在太特殊,1天都不会出现第2次,如果对系统不会造成影响,能不能通融下,做不到!固定窗口算法这时候就会显得太过刚性。

ASP.NET Core中使用滑动窗口限流_第2张图片

那么滑动窗口如何来解决这两个问题呢?还是先来看图:

ASP.NET Core中使用滑动窗口限流_第3张图片

如上图所示:

  • 滑动窗口的时间跨度是1秒,每个小计数周期的时间跨度是500ms,此处的滑动窗口包含2个小计数周期。
  • 随着时间的前进,滑动窗口包含的小计数周期会以500ms为单位向前移动,但始终是包含2个小计数周期。
  • 判断是否限流时,需要将当前滑动窗口包含的2个小计数周期的计数值加起来。
  • 相比固定窗口计数器算法,滑动窗口可以有效减少漏检,如上图滑动窗口移动到了500-1500ms,发现总数超过100,则触发限流;滑动窗口在0-1000ms、1000-2000ms时都不会触发限流,即使其中某个小周期的计数值超过了阈值的半数,但是总数没有超过100,就不会限流,能够应对极少出现的突发流量情况。

从分析还可以看出,滑动窗口的小周期划分的越多,则检测越准确,但用于跟踪的计数也越多,使用的内存和计算量都会增大。

算法实现

这里讲两种实现方法:进程内即内存滑动窗口算法、基于Redis的滑动窗口算法。

进程内即内存滑动窗口算法

这里介绍一种性能比较高的方法,使用数组实现滑动窗口,这是环形队列的一种特例,如下图所示:

ASP.NET Core中使用滑动窗口限流_第4张图片

  • 假设滑动窗口需要5个小的计数周期,则初始化一个长度为5的整形数组,数字表示数组中的第几个元素。
  • 我们知道队列有头有尾,从队头取出数据,向队尾插入数据,带括号的数字表示是队列中的第几个元素。
  • 滑动窗口向前移动时,队尾向右移动1位,同时队头也向右移动1位。
  • 队尾和队头向右移动都可能会溢出数组,此时让它们回到数组的起始位置,即图中数组的第1个位置。

关于这个算法的详细介绍,可以看这篇文章:如何使用数组实现滑动窗口

基于Redis的滑动窗口算法

基于Redis时也可以使用类似环形队列的方法,比如定义5个KV作为数组的5个元素。不过我之前实现时采用了一种更直观的方式,每个小的计数周期都创建一个KV,同时设置一个绝对超过滑动窗口时间跨度的过期时间,用不到的小计数周期不会一直占用内存;判断是否触发限流时,把这些小滑动窗口的计数值累加起来就可以了。当然实际实现时还需要完善一些细节上的处理,比如怎么找到这些小计数周期,会有多种方案,存起来或者临时计算都可以。

这些操作逻辑可以封装在一个Lua script中,因为Lua script在Redis中执行时也是原子操作,所以Redis的限流计数在分布式部署时天然就是准确的。

应用算法

这里以限流组件 FireflySoft.RateLimit 为例,实现ASP.NET Core中的滑动窗口限流。

1、安装Nuget包

有多种安装方式,选择自己喜欢的就行了。

包管理器命令:

Install-Package FireflySoft.RateLimit.AspNetCore

或者.NET命令:

dotnet add package FireflySoft.RateLimit.AspNetCore

或者项目文件直接添加:



2、使用中间件

在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#aspnet


FireflySoft.RateLimit 是一个基于 .NET Standard 的限流类库,其内核简单轻巧,能够灵活应对各种需求的限流场景。

其主要特点包括:

  • 多种限流算法:内置固定窗口、滑动窗口、漏桶、令牌桶四种算法,还可自定义扩展。
  • 多种计数存储:目前支持内存、Redis两种存储方式。
  • 分布式友好:通过Redis存储支持分布式程序统一计数。
  • 限流目标灵活:可以从请求中提取各种数据用于设置限流目标。
  • 支持限流惩罚:可以在客户端触发限流后锁定一段时间不允许其访问。
  • 动态更改规则:支持程序运行时动态更改限流规则。
  • 自定义错误:可以自定义触发限流后的错误码和错误消息。
  • 普适性:原则上可以满足任何需要限流的场景。

Github开源地址:https://github.com/bosima/FireflySoft.RateLimit

收获更多架构知识,请关注公众号 萤火架构。原创内容,转载请注明出处。

你可能感兴趣的:(限流,限流)