当服务受到限制时，一段时间内的请求数将受到限制。简单的点将使用固定的窗口算法（也称为计数算法）。该算法相对简单有效；它并不特别均匀。在某些情况下，会有一些瞬时的突然流量，然后它将迅速恢复正常。很多时候，这不会对系统产生破坏性影响，但是固定的窗口算法无法很好地处理这种情况。
例如，数据查询接口限制每秒100次限制请求，并且大多数时间不会超过此数字，但是偶尔第二个请求将达到120个请求，然后它将快速恢复正常。固定的窗口算法将用于触发电流，用户的正常访问将受到干扰，并且体验不是很好。如果接口的呼叫聚会仍然具有重试的逻辑，则系统可能会在随后的时间窗口中获得更多收件。有更多请求，然后限制更多请求，并生成更多重试请求。循环重新启用系统的负担较重。在严重的情况下，系统可能导致系统崩溃。
假设上一篇文章中的120条请求不会对系统的稳定性产生重大影响，这可以使这种瞬时的突然流量在一定程度上突然流量，以便为用户带来更好的体验。避免进一步恶化系统的问题由于当前的限制，负担。本文介绍了一种用于处理这种情况的令牌存储库的算法。
说了很多话，您如何解决问题？请参阅下面的图：
如上图所示，该算法的基本原理是：有一个令牌桶，容量为x，每个Y单元的时间将放在桶中的钢筋令牌中。请求首先从令牌存储桶中获取令牌，如果您无法获得令牌，请拒绝请求。可以看出，Tokend Barrel算法X，Y和Z的设置尤其重要。Z应该比几次y单位时间内的请求数略多。系统允许携带最大请求，并且系统不能长时间处于此状态。
这是两种实现方法：内存令牌枪管算法，该过程中基于REDIS的令牌枪管算法。
在要求时计算启动的数量，没有单独的处理过程，这比固定的窗口算法更麻烦，但是很容易仔细理解。
使用词典，键是当前的限制目标。值包括当前的令牌到令牌的数量和最后一个令牌时间。在初始状态下，据信，每个当前限制目标的令牌桶已满，即令牌的代币=令牌=令牌桶的容量，但是，只有当在加工这个象征桶中发现的令牌桶。
请求输入后，根据当前限制目标在字典中查找它：
在C＃语言中，您可以使用MemoryCache。它的缓存项目具有到期时间，可以自动恢复一些很少使用或不再使用以减少存储器职业的令牌存储库。
内部算法最适合用于单个实例处理的程序限制。当多个实例处理时，每个实例收到的请求数可能不统一，并且无法保证当前限制效果。
Redis被存储为KV，类似于字典，并且还带有到期时间。处理请求后，首先从请求中提取当前限制目标，然后根据当前限制目标在REDIS中找到它。处理规则与内存算法相同，但使用了两个REDIS KV：
这些操作逻辑可以封装在LUA脚本中。由于LUA脚本在REDIS执行时也是原子操作，因此在分布式部署时，REDIS的当前限制计数自然是准确的。
这是流媒体组件Fireflysoft.RaatElimit作为在ASP.NET Core中实现令牌的示例。
有很多安装方法，只需选择自己喜欢的东西即可。
软件包管理器命令：
或.NET命令：
或直接添加项目文件：
使用启动中的中间件，演示代码如下（下面将有详细说明）：
如果您需要先注册服务，请使用中间部分。
注册服务时，您需要提供限制算法和相应的规则：
基本用途是上述示例。
如果它仍然基于传统.NET框架，则需要在Application_start中注册消息处理器Ratelimithandler。算法和规则已共享。有关详细信息。Raatelimit＃aspnet
fireflysoft.raatelimit是基于.NET标准的当前库。它的内核简单且轻巧，可以灵活地满足各种需求的各种需求。
它的主要特征包括：
github开源地址：https：//github.com/bosima/fireflysoft.raatelimit
获取更多的建筑知识，公共帐户：萤火虫体系结构。