限流器整理

下面介绍几种常用的限流算法，它们分别是计数器算法、漏桶算法和令牌桶算法。

---

计数器算法

---

计数器算法是最简单、最容易想到的限流策略。其本质是限制某个 API 在某个时间窗口内处理请求的次数。我们可以设置一个计数器对某一时间段内的请求进行计数，当请求量超过设定好的阈值时，拒绝用户的请求。例如，限流的 QPS 是100，算法的实现思路是从第一个请求进来开始计数，在接下来的1秒内，每来一个请求计数器自动加1，如果累加的数字超过100，那么后续的请求就会被拒绝，等到1秒结束后，计数器开始重置为0，重新开始计数。然而，这种方式存在弊端：如果在时间窗口的前段时间已经有很多请求达到了阈值，那么后续的请求就会被拒绝，这也称为“突发流量”。

针对计数器算法的漏洞，一个经典的处理方案是采用滑动窗口。例如，我们可以把1分钟内100次请求上限看成一个大的时间窗口，然后把这个窗口进一步细分，比如每10秒一个小窗口，该窗口上限同样设置为100，这样大窗口包含16个小窗口，并且每过10秒大窗口就移动一个小窗口长度。如果一个恶意用户在09:59:30_{09:59:59之间发送了100次请求，等到了10:00:00}10:00:30时，100次计数仍然是有效的，所以，这个时间段新的请求仍然会被拒绝。

---

漏桶算法

---

漏桶算法是另一种常用的限流算法。可以把该算法联想成一个具体的漏桶模型，漏桶始终以一个恒定的速率往外排水，如果桶被装满的话则后来涌入的水会溢出。对应到接口限流来说，用户的请求可以看做是水，能够被处理的请求速率是恒定的，而且能够接受的请求数也是有上限的，超出上限的请求会被拒绝。在算法实现方面，可以准备一个队列来作为漏桶的实现，用这个队列保存请求，通过一个线程池定期从队列中获取请求并执行，也可以一次性获取多个并发请求。然而，漏桶算法也存在一个弊端：无法应对短时间的突发流量。

---

令牌桶算法

---

令牌桶算法是另一种经典的限流算法。在令牌桶算法中，存在一个桶，用来存放固定数量的令牌。算法中存在一种机制，以一定的速率往桶中放令牌。每次请求调用需要先获取令牌，只有拿到令牌才有机会继续执行，否则请求选择等待或者服务直接拒绝请求。放令牌这个动作是持续不断的进行，如果桶中令牌数量达到上限，就丢弃令牌。在这里令牌桶类似一个 buffer，请求密度比较低或者处于冷却状态下，令牌桶会溢出，当请求流量突增时，则过去积累的结余资源直接可以拿来借用，从这里可以看出这点弥补了漏桶算法的不足。实现思路是可以准备一个队列作为令牌桶的实现，用这个队列保存令牌，然后通过一个线程池定期往队列中添加令牌。对于每个请求，需要先从队列中获取令牌，如果令牌不够，则请求被拒绝或者等待，如果令牌够，则请求可以被处理，并从队列中扣除一个令牌。令牌桶算法可以在一定程度上平滑请求流量，保证系统稳定性。

综上所述，计数器算法、漏桶算法和令牌桶算法都是非常常用的限流算法，它们各自有优点和缺点，可以根据实际情况选择合适的算法进行应用。计数器算法简单易懂，但无法应对短时间的突发流量；漏桶算法相对计数器算法更加精细，但也无法应对短时间的突发流量；令牌桶算法可以平滑请求流量，但实现相对较为复杂。