前言
.NET 7 内置了速率限制(Rate Limiting)功能,速率限制指的是限制可访问资源的请求数。例如数据库每分钟可以安全处理 1000 个请求,再多不确定会不会崩。
这时就可以在应用程序中放一个速率限制器,规定每分钟只允许 1000 个请求,在达到这个数量后开始拒绝请求。这是一种保护资源的方法,可以避免应用在高浏览的情况下崩溃。
有很多种不同的算法来控制请求流,下面介绍 .NET 7 中提供的 4 种方法:
并发限制
顾名思义,并发限制器就是限制有多少并发请求可以访问资源。如果限制是 10,那么只有 10 个请求可以同时访问一个资源,第 11 个请求将被拒绝。
一旦前面的请求完成,则允许的请求数量会增加 1,当第二个请求完成时,数量增加到 2,依此类推。该算法是通过 释放 RateLimitLease 来完成的。
令牌桶
令牌桶是另一种算法,就像一个装满令牌的桶。每隔一段时间,桶内会新增固定数量的令牌,但令牌数不能超过桶可容纳的最大数量。当一个请求进来时,它会获取并保存一个令牌,如果存储桶为空,则新请求进入时没有令牌可获取,即将被拒绝访问资源。
假设单个桶可以容纳 10 个令牌,且每分钟往里面加入 2 个令牌。现在有 3 个请求进来了,剩下 7 个令牌。一分钟后,桶自动补充到 9 个令牌,然后 9 个请求瞬间取走所有令牌。那么接下来在桶内添加令牌之前,所有请求都不允许访问资源。如果接下来没有请求,则桶会在 5 分钟内自动补到 10 个令牌,然后等待请求。
固定窗口限制
固定窗口算法使用 “窗口” 的概念,窗口采用时间计量,在固定的一段时间内限制最大请求,并在切换到下一个窗口的时候重置请求数。
假设现在有一个最多只能容纳 100 人(最大请求数)的电影院(窗口),每场电影需要播放 2 个小时(窗口持续时间)。电影开始后,剩下的观众(请求)只能排队等待下一场窗口,排队的最大数量也是 100 ,超出的部分不允许继续排队,只能等待下一个窗口开始后才能继续排队。
滑动窗口限制
滑动窗口算法类似于固定窗口算法,但增加了 “段(segments)” 的概念。
1、一个段是一个窗口的一部分,如果将前面 2 小时的窗口分成 4 个段,则会有 4 个 30 分钟的段。此外还有一个 “段索引”,它始终指向窗口中的最新段。
2、30 分钟内的请求进入最新的段,且每 30 分钟窗口滑动一个段。如果在窗口滑过段期间出现了新的请求,则该请求会被刷新,且段的最大限制会增加。如果没有请求,则段的限制保持不变。
例设现在有一个滑动窗口,它包含 3 个 10 分钟的段,最多只能接受 100 个请求。现在它的初始状态是 3 个段,计数均为 0,当前的段索引指向第 3 个段。
在前 10 分钟内,我们收到 50 个请求,所有请求都在第 3 段(段索引所在的位置)。10 分钟过去后,我们将窗口滑动 1 段,同时将当前段索引移动到第 4 段。
接下来的 10 分钟内,我们又收到了 20 个请求,所以现在第 3 段有 50 个,第 4 段有 20 个。同样在 10 分钟过去后窗口开始滑动,因此当前的段索引指向了 5,而由于段 3 和段 4 都在窗口内,因此窗口只剩 20 个请求名额。
又过了 10 分钟后,再次滑动窗口,这一次窗口滑动后段索引为 6,但段 3(有 50 个请求的段)已位于窗口之外,因此窗口收回了 50 个请求限额。由于段 4 仍有 20 个请求,所以滑动窗口的请求限额变为 80 。
微软博客中有关于速率限制功能和相关 API 、中间件的详细介绍,对此功能感兴趣的朋友可在Nuget中进一步了解。
转自:OSCHINA
链接:oschina.net/news/202961/rate-limiting-for-dotnet