共计 3229 个字符，预计需要花费 9 分钟才能阅读完成。
漏桶算法是限流的四大支流算法之一，其利用场景各种材料中介绍的不多，个别都是说利用在网络流量管制中。这里举两个例子：
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…
播种更多架构常识，请关注公众号 萤火架构。原创内容，转载请注明出处。
