前言

老板提出了一个新需求,从某某天起,免费用户每天只能查询100次,收费用户100w次。

这是一个限流问题,聪明的你也一定想到了如何去做:记录用户每一天的查询次数,然后根据当前用户的类型使用不同的数字做比较,超过指定的数字就返回错误。

嗯,原理就是这么简单。不过真正写起来还要考虑更多问题:

  • 统计数据的数据结构是什么样的?字典 or 行记录?
  • 统计数据记录到哪里?内存 or mysql or redis?
  • 分布式应用怎么精确计数?分布式锁 or 队列 or 事务?
  • 吞吐量比较大时如何扛得住?内存 or redis or 数据库集群?
  • 这些数据要一直保留吗?自动过期 or 定期清理?
  • 如何返回错误?自定义错误 or http标准错误码?

自己去做这些事还是有点麻烦的,这里介绍一个asp.net core的中间件来满足这个限流需求:fireflysoft.ratelimit.aspnetcore。使用步骤如下:

1、安装nuget包

已经发布到nuget.org,有多种安装方式,选择自己喜欢的就行了。

包管理器命令:

install-package fireflysoft.ratelimit.aspnetcore

或者.net命令:

dotnet add package fireflysoft.ratelimit.aspnetcore

或者项目文件直接添加:

<itemgroup>
<packagereference include="fireflysoft.ratelimit.aspnetcore" version="1.2.0" />
</itemgroup>

2、使用中间件

在startup.configure中使用中间件,演示代码如下(下边会有详细说明):

public void configure(iapplicationbuilder app, iwebhostenvironment env)
{
 ...

 app.useratelimit(new ratelimitprocessor<httpcontext>.builder()
  .withalgorithm(new fixedwindowalgorithm<httpcontext>( new[] {
   new fixedwindowratelimitrule<httpcontext>()
   {
    id = "1",
    extracttarget = context =>
    {
     // 这里假设用户id是从cookie中传过来的,需根据实际情况获取
     return context.request.gettypedheaders().get<string>("userid");
    },
    checkrulematching = context =>
    {
     // 这里假设用户类型是从cookie中传过来的,实际可能需要根据用户id再去查询
     // 0免费用户 1收费用户
     int usertype = context.request.gettypedheaders().get<int>("usertype");
     if(usertype==0){
      return true;
     }
     return false;
    },
    name="免费用户限流规则",
    limitnumber=100,
    statwindow=timespan.fromdays(1)
   },
   new fixedwindowratelimitrule<httpcontext>()
   {
    id = "2",
    extracttarget = context =>
    {
     // 这里假设用户id是从cookie中传过来的,需根据实际情况获取
     return context.request.gettypedheaders().get<string>("userid");
    },
    checkrulematching = context =>
    {
     // 这里假设用户类型是从cookie中传过来的,实际可能需要根据用户id再去查询
     // 0免费用户 1收费用户
     int usertype = context.request.gettypedheaders().get<int>("usertype");
     if(usertype==1){
      return true;
     }
     return false;
    },
    name="收费用户限流规则",
    limitnumber=1000000,
    statwindow=timespan.fromdays(1)
   }
  }))
  .witherror(new core.ratelimiterror()
  {
   code=429,
   message = "查询数达到当天最大限制"
  })
  //.withstorage(new redisstorage(stackexchange.redis.connectionmultiplexer.connect("localhost")))
  .build());

 ...
}

使用此中间件需要构建一个名为ratelimitprocessor的限流处理器实例,指定限流处理的请求类型httpcontext,设置限流处理的三个方面:

限流使用的算法以及对应的规则

限流算法,根据这个需求使用固定窗口算法就可以了,也称为计数器算法。此中间件还提供了滑动窗口算法、漏桶算法、令牌桶算法,可以根据需要选择。

不同的限流算法有不同的限流规则类型,在这里使用的是固定窗口限流规则,针对免费用户和收费用户分别定义了两个规则,注意其中的几个参数:

  • id:在当前的版本中id必须手动指定,并且不能重复。
  • extracttarget:传递一个方法用于从请求中提取限流目标,这里就是用户id。
  • checkrulematching传递一个方法用于检查当前请求是否适用当前规则,这里根据用户类型进行判断。
  • statwindow是固定窗口的大小,是一个时间跨度,这里是1天。
  • limitnumber是限流值,在statwindow时间内请求数超过它就会触发限流。

这里有两个比较有意思的设置:extracttarget和checkrulematching,他们共同作用,让用户可以完全自由的定制自己限流的目标和条件,无论是ip、clientid或者url。

限流统计数据的持久化方式

fireflysoft.ratelimit中的限流计数目前支持保存在内存或者redis中,也可以通过实现iratelimitstorage来定义一个新的存储器,不设置时默认为内存存储。

对于只需要部署一份的程序,绝大部分情况下使用内存就够了;但是如果限流的时间窗口比较长,比如1小时限制300次,重启就会丢失计数,这可能是个风险,此时使用redis会比较合适。对于分布式应用,也建议使用redis存储。

限流统计数据会根据限流时间窗口自动过期移除。

被限流时的错误码和消息

默认限流错误code是429,这个会作为httpstatuscode返回;message默认为null,你可以修改为自己的任意文字提示,这个会作为http body的内容返回。

以上就是使用fireflysoft.ratelimit.aspnetcore对不同类型的用户进行区别限流的使用方法。

如果觉得还是限制的有点死,比如返回错误信息部分,想返回一个json格式的错误消息,还可以使用fireflysoft.ratelimit.core这个包来封装自己的asp.net core中间件。

如果想在这个程序的基础上再改造下,可以fork这个项目:https://github.com/bosima/fireflysoft.ratelimit

总结

到此这篇关于asp.net core对不同类型的用户进行区别限流的文章就介绍到这了,更多相关asp.net core用户区别限流内容请搜索www.887551.com以前的文章或继续浏览下面的相关文章希望大家以后多多支持www.887551.com!