程序员，AI探索者

FireflySoft.RateLimit自2021年1月发布第一个版本以来，经历了多次升级迭代，目前已经十分稳定，被很多开发者应用到了生产系统中，最新发布的版本是3.0.0。

最近经常看到某某主播被直播平台限流惩罚，平台给主播的流量变少，甚至直接没有流量了。这篇文章要说的是后端服务的限流惩罚，和这个主播被限流惩罚有点相似之处，又有些不同。本文说的限流惩罚是什么样的？服务调用者调用服务的次数超过了服务允许的最大上限，也就是达到了限流阈值，此时服务会返回一个限流错误给调用方，同时还要对调用方追加一些惩罚措施，比如限制调用方10秒钟之内都不能访问服务。为什么被限流了还要追加惩罚？这里边的逻辑是：调用方之所以被限流，就是因为没有合理的使用服务（当然这个合理性是由服务提供方来声明的

在限流算法中有一种令牌桶算法，该算法可以应对短暂的突发流量，这对于现实环境中流量不怎么均匀的情况特别有用，不会频繁的触发限流，对调用方比较友好。例如，当前限制10qps，大多数情况下不会超过此数量，但偶尔会达到30qps，然后很快就会恢复正常，假设这种突发流量不会对系统稳定性产生影响，我们可以在一定程度上允许这种瞬时突发流量，从而为用户带来更好的可用性体验。这就是使用令牌桶算法的地方。令牌桶算法原理如下图所示，该算法的基本原理是：有一个容量为X的令牌桶，每Y单位时间内将Z个令牌放入该桶。如果桶中的令牌

问题在业务应用程序开发中，经常遇到用户重复提交的问题。比如有一个报名的表单，如果用户不小心连续点击了提交按钮多次，数据库中就可能产生多条报名记录；再或者正常提交后，因为网络或者服务端的原因，前端没有及时收到提交结果，则用户可能认为自己没有提交成功，然后再次甚至多次提交，数据库中也可能产生多条此用户的报名记录。这个例子中的情况还不会对业务造成多大影响，如果是涉及到资源增减的场景，比如账户、库存等的操作，可能就比较麻烦了。对于解决问题的办法，你可能会说，前端提交后锁住按钮不就可以了嘛！确实能够解决一部分

在服务限流时一般会限制某个时间周期内的请求数，简单点会采用固定窗口算法（也称计数器算法），这种算法实现相对简单，也很高效；但在实际的应用场景中请求并不是特别均匀，某些情况下会产生一些瞬时的突发流量，然后很快恢复正常，很多时候这并不会对系统产生破坏性的影响，但是固定窗口算法不能很好的处理这种情况。比如某个数据查询接口限流每秒100次请求，绝大多数的时间里都不会超过这个数，但是偶尔某一秒钟会达到120次请求，接着很快又会恢复正常。此时如果采用固定窗口算法会触发限流，用户的正常访问会被干扰，体验上不太好；如果接

算法原理固定窗口算法又称计数器算法，是一种简单的限流算法。在单位时间内设定一个阈值和一个计数值，每收到一个请求则计数值加一，如果计数值超过阈值则触发限流，如果达不到则请求正常处理，进入下一个单位时间后，计数值清零，重新累计。如上图所示，时间单位是1秒，阈值是3。第1秒3个请求，不会触发限流；第2秒1个请求，不会触发限流；第3秒4个请求，这一秒的前3个请求正常处理，第4个请求触发限流，会被拒绝处理。后续第4秒、第5秒不会触发限流，所有请求正常处理。算法实现这里讲两种实现方法：进程

滑动窗口算法用于应对请求在时间周期中分布不均匀的情况，能够更精确的应对流量变化，比较著名的应用场景就是TCP协议的流量控制，不过今天要说的是服务限流场景中的应用。算法原理这里假设业务需要每秒钟限流100次，先来看固定窗口算法的两个问题：漏检如下图所示，单看第1秒和第2秒，其请求次数都没有超过100，所以使用固定窗口算法时不会触发限流。但是第1秒的后500ms的请求数加上第2秒的前500毫秒的请求数就超过了100，这时候可能会给系统带来伤害，使用固定窗口算法时不能检测到这种情况。 太刚针

自FireflySoft.RateLimit发布以来，帮助了不少需要在.net中进行限流处理的用户。前段时间有个开发者发了一个pull request，大意是Redis重启的时候Lua script会丢失，但是程序中还认为它存在，所以就会一直抛出异常，那位同学通过捕捉一个特定异常再reload Lua script的方式解决了这个问题。经过一段时间的测，试运行良好，因为这个问题还是相对常见的，所以就发布了一个版本 2.0.2，建议通过nuget尽快升级。前段时间还有用户问怎么在程序执行过程中动态更改限流的

漏桶算法是限流的四大主流算法之一，其应用场景各种资料中介绍的不多，一般都是说应用在网络流量控制中。这里举两个例子：1、目前家庭上网都会限制一个固定的带宽，比如100M、200M等，一栋楼有很多的用户，那么运营商怎么保证某些用户没有使用过多的带宽，从而影响到别人呢？这时就可以使用漏桶算法，限制每个用户访问网络的最大带宽，当然实际会比这复杂很多。2、有一个祖传接口，当时写的时候没有任何保护措施，现在访问量稍微大点就会崩溃，但是代码谁也改不动。这时候也可以用漏桶算法，把这个接口封装一下，将外部请求通过漏桶算法

漏桶算法是限流的四大主流算法之一，其应用场景各种资料中介绍的不多，一般都是说应用在网络流量控制中。这里举两个例子：1、目前家庭上网都会限制一个固定的带宽，比如100M、200M等，一栋楼有很多的用户，那么运营商怎么保证某些用户没有使用过多的带宽，从而影响到别人呢？这时就可以使用漏桶算法，限制每个用户访问网络的最大带宽，当然实际会比这复杂很多。2、有一个祖传接口，当时写的时候没有任何保护措施，现在访问量稍微大点就会崩溃，但是代码谁也改不动。这时候也可以用漏桶算法，把这个接口封装一下，将外部请求通过漏桶算法

这两年因为疫情，节假日都不怎么外出了，以前每逢节假日都要提前一个月或者半个月抢火车票，人太多的时候会把12306整崩溃。当时很多技术人员指点江山，激扬想法，粪土当年铁科院。

老板提出了一个新需求，从某某天起，免费用户每天只能查询100次，收费用户100W次。这是一个限流问题，聪明的你也一定想到了如何去做：记录用户每一天的查询次数，然后根据当前用户的类型使用不同的数字做比较，超过指定的数字就返回错误。嗯，原理就是这么简单。不过真正写起来还要考虑更多问题：统计数据的数据结构是什么样的？字典 or 行记录？ 统计数据记录到哪里？内存 or MySQL or Redis？ 分布式应用怎么精确计数？分布式锁 or 队列 or 事务？ 吞吐量比较大时如何扛得住？内存 or