漏桶算法是限流的四大支流算法之一，其利用场景各种材料中介绍的不多，个别都是说利用在网络流量管制中。这里举两个例子：

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/Fir...

FireflySoft.RateLimit 是一个基于 .NET Standard 的限流类库，其内核简略笨重，可能灵便应答各种需要的限流场景。

其次要特点包含：

多种限流算法：内置固定窗口、滑动窗口、漏桶、令牌桶四种算法，还可自定义扩大。
多种计数存储：目前反对内存、Redis两种存储形式。
分布式敌对：通过Redis存储反对分布式程序对立计数。
限流指标灵便：能够从申请中提取各种数据用于设置限流指标。
反对限流惩办：能够在客户端触发限流后锁定一段时间不容许其拜访。
动静更改规定：反对程序运行时动静更改限流规定。
自定义谬误：能够自定义触发限流后的错误码和谬误音讯。
普适性：原则上能够满足任何须要限流的场景。

Github开源地址：https://github.com/bosima/Fir...

播种更多架构常识，请关注公众号萤火架构。原创内容，转载请注明出处。