限流系列

开源组件 rate-limit: 限流

高可用之限流-01-入门介绍

高可用之限流-02-如何设计限流框架

高可用之限流-03-Semaphore 信号量做限流

高可用之限流-04-fixed window 固定窗口

高可用之限流-05-slide window 滑动窗口

高可用之限流-06-slide window 滑动窗口 sentinel 源码

高可用之限流-07-token bucket 令牌桶算法

高可用之限流 08-leaky bucket漏桶算法

高可用之限流 09-guava RateLimiter 入门使用简介 & 源码分析

背景

在如今的互联网已经作为社会基础设施的大环境下，上面的这个场景其实离我们并不是那么远，同时也会显得没那么极端。

例如，层出不穷的营销玩法，一个接着一个的社会热点，以及互联网冰山之下的黑产、刷子的蓬勃发展，更加使得这个场景变的那么的需要去考虑、去顾忌。

因为随时都有可能会涌入超出你预期的流量，然后压垮你的系统。

那么限流的作用就很显而易见了：只要系统没宕机，系统只是因为资源不够，而无法应对大量的请求，为了保证有限的系统资源能够提供最大化的服务能力，因而对系统按照预设的规则进行流量（输出或输入）限制的一种方法，确保被接收的流量不会超过系统所能承载的上限。

限流

服务治理本身的概念比较大，包括鉴权、限流、降级、熔断、监控告警等等。

场景需求

比如限制微服务集群单台机器每秒请求次数，我们还需要针对不同调用方甚至不同接口进行更加细粒度限流：比如限制 A 调用方对某个服务的某个的接口的每秒最大请求次数。

流

限流中的“流”字该如何解读呢？要限制的指标到底是什么？

不同的场景对“流”的定义也是不同的，可以是网络流量，带宽，每秒处理的事务数 (TPS)，每秒请求数 (hits per second)，并发请求数，甚至还可能是业务上的某个指标，比如用户在某段时间内允许的最多请求短信验证码次数。

从保证系统稳定可用的角度考量，对于微服务系统来说，最好的一个限流指标是：并发请求数。

通过限制并发处理的请求数目，可以限制任何时刻都不会有过多的请求在消耗资源，比如：我们通过配置 web 容器中 servlet worker 线程数目为 200，则任何时刻最多都只有 200 个请求在处理，超过的请求都会被阻塞排队。

对比 TPS 和 hits per second 的两个指标，我们选择使用 hits per second 作为限流指标。

因为，对 TPS 的限流实际上是无法做的，TPS 表示每秒处理事务数，事务的开始是接收到接口请求，事务的结束是处理完成返回，所以有一定的时间跨度，如果事务开始限流计数器加一，事务结束限流计数器减一，则就等同于并发限流。

而如果把事务请求接收作为计数时间点，则就退化为按照 hits per second 来做限流，而如果把事务结束作为计数时间点，则计数器的数值并不能代表系统当下以及接下来的系统访问压力。

对 hits per second 的限流是否是一个有效的限流指标呢？答案是肯定的，这个值是可观察可统计的，所以方便配置限流规则，而且这个值在一定程度上反应系统当前和接下来的性能压力，对于这一指标的限流确实也可以达到限制对系统资源的使用。

有了流的定义之后，我们接下来看几种常用的限流算法：固定时间窗口，滑动时间窗口，令牌桶算法，漏桶算法以及他们的改进版本。

常见算法固定时间窗口

首先需要选定一个时间起点，之后每次接口请求到来都累加计数器，如果在当前时间窗口内，根据限流规则（比如每秒钟最大允许 100 次接口请求），累加访问次数超过限流值，则限流熔断拒绝接口请求。

当进入下一个时间窗口之后，计数器清零重新计数。

限流策略过于粗略，无法应对两个时间窗口临界时间内的突发流量。

我们举一个例子：假设我们限流规则为每秒钟不超过 100 次接口请求，第一个 1s 时间窗口内，100 次接口请求都集中在最后的 10ms 内，在第二个 1s 的时间窗口内，100 次接口请求都集中在最开始的 10ms 内，虽然两个时间窗口内流量都符合限流要求 (