老板提出了一个新需求，从某某天起，免用度户天天只能查询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; },, 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; },, 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对差异范例的用户举办区别限流的利用要领。