解决ASP.NET Core中使用漏桶算法限流的问题

目录
  • 算法原理
  • 算法实现
    • 进程内即内存漏桶算法
    • 基于Redis的漏桶算法
  • 应用算法
    • 1、安装Nuget包
    • 2、使用中间件

漏桶算法是限流的四大主流算法之一,其应用场景各种资料中介绍的不多,一般都是说应用在网络流量控制中。这里举两个例子:

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也可以实现上述的算法,只不过变量的表示方式换成了Redis 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

或者项目文件直接添加:

<ItemGroup>
<PackageReference Include="FireflySoft.RateLimit.AspNetCore" Version="2.*" />
</ItemGroup>

2、使用中间件

在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存储支持分布式程序统一计数。
  • 限流目标灵活:可以从请求中提取各种数据用于设置限流目标。
  • 支持限流惩罚:可以在客户端触发限流后锁定一段时间不允许其访问。
  • 动态更改规则:支持程序运行时动态更改限流规则。
  • 自定义错误:可以自定义触发限流后的错误码和错误消息。
  • 普适性:原则上可以满足任何需要限流的场景。

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

到此这篇关于ASP.NET Core中使用漏桶算法限流的文章就介绍到这了,更多相关ASP.NET Core限流内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • ASP.NET Core中使用滑动窗口限流的问题及场景分析

    目录 算法原理 漏检 太刚 算法实现 进程内即内存滑动窗口算法 基于Redis的滑动窗口算法 应用算法 1.安装Nuget包 2.使用中间件 滑动窗口算法用于应对请求在时间周期中分布不均匀的情况,能够更精确的应对流量变化,比较著名的应用场景就是TCP协议的流量控制,不过今天要说的是服务限流场景中的应用. 算法原理 这里假设业务需要每秒钟限流100次,先来看固定窗口算法的两个问题: 漏检 如下图所示,单看第1秒和第2秒,其请求次数都没有超过100,所以使用固定窗口算法时不会触发限流.但是第1秒的后

  • ASP.NET Core对不同类型的用户进行区别限流详解

    前言 老板提出了一个新需求,从某某天起,免费用户每天只能查询100次,收费用户100W次. 这是一个限流问题,聪明的你也一定想到了如何去做:记录用户每一天的查询次数,然后根据当前用户的类型使用不同的数字做比较,超过指定的数字就返回错误. 嗯,原理就是这么简单.不过真正写起来还要考虑更多问题: 统计数据的数据结构是什么样的?字典 or 行记录? 统计数据记录到哪里?内存 or MySQL or Redis? 分布式应用怎么精确计数?分布式锁 or 队列 or 事务? 吞吐量比较大时如何扛得住?内存

  • ASP.NET Core中使用令牌桶限流的实现

    在限流时一般会限制每秒或每分钟的请求数,简单点一般会采用计数器算法,这种算法实现相对简单,也很高效,但是无法应对瞬时的突发流量. 比如限流每秒100次请求,绝大多数的时间里都不会超过这个数,但是偶尔某一秒钟会达到120次请求,接着很快又会恢复正常,假设这种突发的流量不会对系统稳定性带来实质性的影响,则可以在一定程度上允许这种瞬时的突发流量,从而为用户带来更好的可用性体验.这就是令牌桶算法的用武之地. 该算法的基本原理是:有一个令牌桶,容量是X,每Y单位时间会向桶中放入Z个令牌,如果桶中的令牌数超

  • Asp.NET Core 限流控制(AspNetCoreRateLimit)的实现

    起因: 近期项目中,提供了一些调用频率较高的api接口,需要保障服务器的稳定运行:需要对提供的接口进行限流控制.避免因客户端频繁的请求导致服务器的压力. 一.AspNetCoreRateLimit 介绍 AspNetCoreRateLimit 是一个ASP.NET Core速率限制的解决方案,旨在控制客户端根据IP地址或客户端ID向Web API或MVC应用发出的请求的速率.AspNetCoreRateLimit包含一个 IpRateLimitMiddleware 和 ClientRateLim

  • ASP.NET Core使用固定窗口限流

    目录 算法原理 算法实现 进程内即内存固定窗口算法 基于Redis的固定窗口算法 算法应用 1.安装Nuget包 2.使用中间件 算法原理 固定窗口算法又称计数器算法,是一种简单的限流算法.在单位时间内设定一个阈值和一个计数值,每收到一个请求则计数值加一,如果计数值超过阈值则触发限流,如果达不到则请求正常处理,进入下一个单位时间后,计数值清零,重新累计. 如上图所示,时间单位是1秒,阈值是3. 第1秒3个请求,不会触发限流: 第2秒1个请求,不会触发限流: 第3秒4个请求,这一秒的前3个请求正常

  • 解决ASP.NET Core中使用漏桶算法限流的问题

    目录 算法原理 算法实现 进程内即内存漏桶算法 基于Redis的漏桶算法 应用算法 1.安装Nuget包 2.使用中间件 漏桶算法是限流的四大主流算法之一,其应用场景各种资料中介绍的不多,一般都是说应用在网络流量控制中.这里举两个例子: 1.目前家庭上网都会限制一个固定的带宽,比如100M.200M等,一栋楼有很多的用户,那么运营商怎么保证某些用户没有使用过多的带宽,从而影响到别人呢?这时就可以使用漏桶算法,限制每个用户访问网络的最大带宽,当然实际会比这复杂很多. 2.有一个祖传接口,当时写的时

  • 三种方法解决ASP.NET Core 6中的依赖项

    依赖性注入是一种技术,它允许我们注入一个特定类的依赖对象,而不是直接创建这些实例. 使用依赖注入的好处显而易见,它通过放松模块间的耦合,来增强系统的可维护性和可测试性. 依赖注入允许我们修改具体实现,而不必改变依赖于它们的依赖类型. ASP.NET Core 很重视依赖注入技术.ASP.NET Core 中内置的依赖注入提供功能模块,并不像 StructureMap 和 Ninject 等IoC(控制反转)容器那样功能丰富,但它速度快,易于配置,而且易于使用.我们可以使用它在 ASP.NET C

  • 谈谈如何在ASP.NET Core中实现CORS跨域

    CORS(Cross-origin resource sharing)是一个W3C标准,翻译过来就是 "跨域资源共享",它主要是解决Ajax跨域限制的问题. CORS需要浏览器和服务器支持,现在所有现代浏览器都支持这一特性.注:IE10及以上 只要浏览器支持,其实CORS所有的配置都是在服务端进行的,而前端的操作浏览器会自动完成. 在本例中,将演示如何再ASP.NET Core中实现CORS跨域. 前期准备 你需要windows系统. 你需要安装IIS. 推荐使用VS2015 Upda

  • 详解ASP.Net Core 中如何借助CSRedis实现一个安全高效的分布式锁

    引言:最近回头看了看开发的.Net Core 2.1项目的复盘总结,其中在多处用到Redis实现的分布式锁,虽然在OnResultExecuting方法中做了防止死锁的处理,但在某些场景下还是会发生死锁的问题,下面我只展示部分代码: 问题: (1)这里setnx设置的值"1",我想问,你最后del的这个值一定是你自己创建的吗? (2)图中标注的步骤1和步骤2不是原子操作,会有死锁的概率吗? 大家可以思考一下先,下面让我们带着这两个问题往下看,下面介绍一下使用Redis实现分布式锁常用的

  • ASP.NET Core中预压缩静态文件的方法步骤

    前言 Web应用程序的优化是非常重要,因为使用更少的CPU,占用更少的带宽可以减少项目的费用. 在ASP.NET Core中我们可以很容易的启用响应压缩,但是针对预压缩文件,就需要做一些额外的功能了. 这篇博客文章展示了如何在ASP.NET Core中预压缩静态文件. 下面话不多说了,来一起看看详细的介绍吧 为什么需要预压缩文件? 虽然在从服务器请求文件时, 我们可以动态压缩文件,但这意味这Web服务器需要做更多的额外工作. 其实只有在新的应用程序部署时才会更改要压缩的文件. 越好的压缩效果需要

  • ASP.NET Core中的Action的返回值类型实现

    在Asp.net Core之前所有的Action返回值都是ActionResult,Json(),File()等方法返回的都是ActionResult的子类.并且Core把MVC跟WebApi合并之后Action的返回值体系也有了很大的变化. ActionResult类 ActionResult类是最常用的返回值类型.基本沿用了之前Asp.net MVC的那套东西,使用它大部分情况都没问题.比如用它来返回视图,返回json,返回文件等等.如果是异步则使用Task. public class Te

  • Asp.Net Core 中的“虚拟目录”实现

    写在前面 现在部署Asp.Net Core应用已经不再限制于Windows的IIS上,更多的是Docker容器.各种反向代理来部署.也有少部分用IIS部署的,IIS部署确实是又快又简单,图形化操作三下五除二就可以发布好一个系统了.在过去Asp.Net MVC 项目部署的时候,还常常使用IIS一个功能--虚拟目录. 虚拟目录可以直接定位到非项目的其他路径,将路径作为网站的一部分,可实现上传文件保存到其他盘符或间接的使用项目以外的静态文件.在Asp.Net MVC中从虚拟路径中存取文件也很简单,如S

  • 如何在Asp.Net Core中集成Refit

    在很多时候我们在不同的服务之间需要通过HttpClient进行及时通讯,在我们的代码中我们会创建自己的HttpClient对象然后去跨领域额进行数据的交互,但是往往由于一个项目有多个人开发所以在开发中没有人经常会因为不同的业务请求去写不同的代码,然后就会造成各种风格的HttpClient的跨域请求,最重要的是由于每个人对HttpClient的理解程度不同所以写出来的代码可能质量上会有参差不齐,即使代码能够达到要求往往也显得非常臃肿,重复高我们在正式介绍Refit这个项目之前,我们来看看我们在项目

随机推荐