针对软件系统来说，限流就是对请求的速率进行限制，避免瞬时的大量请求击垮软件系统。毕竟，软件系统的处理能力是有限的。如果说超过了其处理能力的范围，软件系统可能直接就挂掉了。

限流可能会导致用户的请求无法被正确处理或者无法立即被处理，不过，这往往也是权衡了软件系统的稳定性之后得到的最优解。

现实生活中，处处都有限流的实际应用，就比如排队买票是为了避免大量用户涌入购票而导致售票员无法处理。

常见限流算法有哪些？

固定窗口计数器算法

固定时间窗口计数器算法规定了系统单位时间处理的请求数量。比如

假如我们规定系统中某个接口 1 分钟只能被访问 33 次的话，计数器记录当前分钟请求次数，每分钟33次以内的请求会被正常处理，超过的直接全部拒绝，每分钟重置。

优点：实现简单，易于理解。

缺点：

• 限流不够平滑。例如，我们限制某个接口每分钟只能访问 30 次，假设前 30 秒就有 30 个请求到达的话，那后续 30 秒将无法处理请求，这是不可取的，用户体验极差！
• 无法保证限流速率，因而无法应对突然激增的流量。例如，我们限制某个接口 1 分钟只能访问 1000 次，该接口的 QPS 为 500，前 55s 这个接口 1 个请求没有接收，后 1s 突然接收了 1000 个请求。然后，在当前场景下，这 1000 个请求在 1s 内是没办法被处理的，系统直接就被瞬时的大量请求给击垮了。

滑动窗口计数器算法

相较于固定窗口计数器，它把时间以一定比例分片，比如限流每分钟处理 60 个请求，我们可以把 1 分钟分为 60 个窗口。每个窗口只能处理不大于 60(请求数)/60（窗口数） 的请求

优点：

• 相比于固定窗口算法，滑动窗口计数器算法可以应对突然激增的流量。
• 相比于固定窗口算法，滑动窗口计数器算法的颗粒度更小，可以提供更精确的限流控制。

缺点：

• 与固定窗口计数器算法类似，滑动窗口计数器算法依然存在限流不够平滑的问题。
• 相比较于固定窗口计数器算法，滑动窗口计数器算法实现和理解起来更复杂一些。

漏桶算法

我们可以把发请求的动作比作成注水到桶中，我们处理请求的过程可以比喻为漏桶漏水。我们往桶中以任意速率流入水，以一定速率流出水。当水超过桶流量则丢弃，因为桶容量是不变的，保证了整体的速率。

如果想要实现这个算法的话也很简单，准备一个队列用来保存请求，然后我们定期从队列中拿请求来执行就好了（和消息队列削峰/限流的思想是一样的）。

优点：

• 实现简单，易于理解。
• 可以控制限流速率，避免网络拥塞和系统过载。

缺点：

• 无法应对突然激增的流量，因为只能以固定的速率处理请求，对系统资源利用不够友好。
• 桶流入水（发请求）的速率如果一直大于桶流出水（处理请求）的速率的话，那么桶会一直是满的，一部分新的请求会被丢弃，导致服务质量下降。

实际业务场景中，基本不会使用漏桶算法。

令牌桶算法

令牌桶算法也比较简单。和漏桶算法算法一样，我们的主角还是桶（这限流算法和桶过不去啊）。不过现在桶里装的是令牌了，请求在被处理之前需要拿到一个令牌，请求处理完毕之后将这个令牌丢弃（删除）。我们根据限流大小，按照一定的速率往桶里添加令牌。如果桶装满了，就不能继续往里面继续添加令牌了。

优点：

• 可以限制平均速率和应对突然激增的流量。
• 可以动态调整生成令牌的速率。

缺点：

• 如果令牌产生速率和桶的容量设置不合理，可能会出现问题比如大量的请求被丢弃、系统过载。
• 相比于其他限流算法，实现和理解起来更复杂一些。

针对什么来进行限流？

实际项目中，还需要确定限流对象，也就是针对什么来进行限流。常见的限流对象如下：

• IP ：针对 IP 进行限流，适用面较广，简单粗暴。

  • 通过 req.headers['x-forwarded-for'] 获取请求的 ip ，可能被伪造，但是较为简单。

• 业务 ID：挑选唯一的业务 ID 以实现更针对性地限流。例如，基于用户 ID 进行限流。

• 个性化：根据用户的属性或行为，进行不同的限流策略。例如， VIP 用户不限流，而普通用户限流。根据系统的运行指标（如 QPS、并发调用数、系统负载等），动态调整限流策略。例如，当系统负载较高的时候，控制每秒通过的请求减少。

单机限流怎么做？

单机限流针对的是单体架构应用。

单机限流可以直接使用 Google Guava 自带的限流工具类 RateLimiter 。 RateLimiter 基于令牌桶算法，可以应对突发流量。

Guava 地址：https://github.com/google/guava

除了最基本的令牌桶算法(平滑突发限流)实现之外，Guava 的RateLimiter还提供了 平滑预热限流 的算法实现。

平滑突发限流就是按照指定的速率放令牌到桶里，而平滑预热限流会有一段预热时间，预热时间之内，速率会逐渐提升到配置的速率。

分布式限流怎么做？

分布式限流常见的方案：

• 借助中间件限流：可以借助 Sentinel 或者使用 Redis 来自己实现对应的限流逻辑。
• 网关层限流：比较常用的一种方案，直接在网关层把限流给安排上了。不过，通常网关层限流通常也需要借助到中间件/框架。就比如 Spring Cloud Gateway 的分布式限流实现RedisRateLimiter就是基于 Redis+Lua 来实现的，再比如 Spring Cloud Gateway 还可以整合 Sentinel 来做限流。