前言

什么是限流

在日常生活中限流很常见，例如去有些景区玩，每天售卖的门票数是有限的，例如 2000 张，即每天最多只有 2000 个人能进去游玩。
那在我们工程上限流是什么呢？限制的是 「流」，在不同场景下「流」的定义不同，可以是每秒请求数、每秒事务处理数、网络流量等等。

而通常我们说的限流指代的是限制到达系统的并发请求数，使得系统能够正常的处理部分用户的请求，来保证系统的稳定性。

限流不可避免的会造成用户的请求变慢或者被拒的情况，从而会影响用户体验。
因此限流是需要在用户体验和系统稳定性之间做平衡的，即我们常说的 trade off。

限流也称流控（流量控制）。
每个系统都有服务的上线，所以当流量超过服务极限能力时，系统可能会出现卡死、崩溃的情况，所以就有了降级和限流。
限流其实就是：当高并发或者瞬时高并发时，为了保证系统的稳定性、可用性，系统以牺牲部分请求为代价或者延迟处理请求为代价，保证系统整体服务可用。

为什么要限流

日常的业务上有类似秒杀活动、双十一大促或者突发新闻等场景，用户的流量突增，后端服务的处理能力是有限的，如果不能处理好突发流量，后端服务很容易就被打垮。
亦或是爬虫等不正常流量，我们对外暴露的服务都要以最大恶意去防备调用者。
我们不清楚调用者会如何调用我们的服务，假设某个调用者开几十个线程一天二十四小时疯狂调用你的服务，如果不做啥处理咱服务也算完了，更胜的还有DDos攻击。
还有对于很多第三方开放平台来说，不仅仅要防备不正常流量，还要保证资源的公平利用，一些接口都免费给你用了，资源都不可能一直都被你占着吧，别人也得调的。

限流的本质是因为后端处理能力有限，需要截掉超过处理能力之外的请求，亦或是为了均衡客户端对服务端资源的公平调用，防止一些客户端饿死。

常见的限流算法

1. 计数器

最简单的限流算法就是计数限流了。

例如系统能同时处理 100 个请求，保存一个计数器，处理了一个请求，计数器就加一，一个请求处理完毕之后计数器减一。
每次请求来的时候看看计数器的值，如果超过阈值就拒绝。
非常简单粗暴。

计数器的值要是存内存中就算单机限流算法；如果放在第三方存储里，例如 Redis 中，集群机器访问就算分布式限流算法。

优点就是：简单粗暴，单机在 Java 中可用 Atomic 等原子类、分布式就 Redis incr。
缺点就是：假设我们允许的阈值是1万，此时计数器的值为 0， 当 1 万个请求在前 1 秒内一股脑儿的都涌进来，这突发的流量可是顶不住的。
缓缓地增加流量处理和一下子涌入对于程序来说是不一样的。

  • 采用AtomicInteger
  • 采用令牌Semaphore
  • 采用ThreadPoolExecutor java线程池

2. 固定窗口

一般的限流都是为了限制在指定时间间隔内的访问量，因此还有个算法叫固定窗口。

相比于计数限流主要是多了个时间窗口的概念，计数器每过一个时间窗口就重置。
规则如下：

  • 请求次数小于阈值，允许访问并且计数器 +1；
  • 请求次数大于阈值，拒绝访问；
  • 这个时间窗口过了之后，计数器清零；

固定窗口临界问题

假设系统每秒允许 100 个请求，假设第一个时间窗口是 0-1s，在第 0.55s 处一下次涌入 100 个请求，过了 1 秒的时间窗口后计数清零，此时在 1.05 s 的时候又一下次涌入100个请求。
虽然窗口内的计数没超过阈值，但是全局来看在 0.55s-1.05s 这 0.1 秒内涌入了 200 个请求，这其实对于阈值是 100/s 的系统来说是无法接受的。

3. 滑动窗口

滑动窗口限流解决固定窗口临界值的问题，可以保证在任意时间窗口内都不会超过阈值。
相对于固定窗口，滑动窗口除了需要引入计数器之外，还需要记录时间窗口内每个请求到达的时间点，因此对内存的占用会比较多。

规则如下，假设时间窗口为 1 秒：

  • 记录每次请求的时间
  • 统计每次请求的时间 至 往前推1秒这个时间窗口内请求数，并且 1 秒前的数据可以删除。
  • 统计的请求数小于阈值就记录这个请求的时间，并允许通过，反之拒绝。


短时间内的流量暴击

滑动窗口和固定窗口都无法解决短时间之内集中流量的突击。

我们所想的限流场景是：
每秒限制 100 个请求。希望请求每 10ms 来一个，这样我们的流量处理就很平滑，但是真实场景很难控制请求的频率，因此可能存在 5ms 内就打满了阈值的情况。
当然对于这种情况还是有变型处理的，例如设置多条限流规则。不仅限制每秒 100 个请求，再设置每 10ms 不超过 2 个。

多说一句，这个滑动窗口可与TCP的滑动窗口不一样。
TCP的滑动窗口是接收方告知发送方自己能接多少“货”，然后发送方控制发送的速率。

4. 漏桶

漏桶，它可以解决时间窗口类的痛点，使得流量更加平滑。

如下图所示，水滴持续滴入漏桶中，底部定速流出。
如果水滴滴入的速率大于流出的速率，当存水超过桶的大小的时候就会溢出。

规则如下：

  • 请求来了放入桶中
  • 桶内请求量满了拒绝请求
  • 服务定速从桶内拿请求处理

可以看到水滴对应的就是请求。
它的特点就是宽进严出，无论请求多少，请求的速率有多大，都按照固定的速率流出，对应的就是服务按照固定的速率处理请求。

看到这想到啥，是不是和消息队列思想有点像，削峰填谷。
一般而言漏桶也是由队列来实现的，处理不过来的请求就排队，队列满了就开始拒绝请求。
看到这又想到啥，线程池不就是这样实现的嘛？

经过漏洞这么一过滤，请求就能平滑的流出，看起来很像很挺完美的？实际上它的优点也即缺点。
面对突发请求，服务的处理速度和平时是一样的，这其实不是我们想要的。
在面对突发流量我们希望在系统平稳的同时，提升用户体验即能更快的处理请求，而不是和正常流量一样，循规蹈矩的处理（看看，之前滑动窗口说流量不够平滑，现在太平滑了又不行，难搞啊）。

而令牌桶在应对突击流量的时候，可以更加的“激进”。

5. 令牌桶算法

令牌桶其实和漏桶的原理类似，只不过漏桶是定速地流出，而令牌桶是定速地往桶里塞入令牌，然后请求只有拿到了令牌才能通过，之后再被服务器处理。
当然令牌桶的大小也是有限制的，假设桶里的令牌满了之后，定速生成的令牌会丢弃。

规则：

  • 定速的往桶内放入令牌
  • 令牌数量超过桶的限制，丢弃
  • 请求来了先向桶内索要令牌，索要成功则通过被处理，反之拒绝

看到这又想到啥？Semaphore信号量，信号量可控制某个资源被同时访问的个数，其实和咱们拿令牌思想一样，一个是拿信号量，一个是拿令牌。
只不过信号量用完了返还，而咱们令牌用了不归还，因为令牌会定时再填充。

应对突发流量的时候，桶内假如有 100 个令牌，那么这 100 个令牌可以马上被取走，而不像漏桶那样匀速的消费。
所以在应对突发流量的时候令牌桶表现的更佳。

小结

  • 拿令牌桶来说
    • 假设你没预热，那是不是上线时候桶里没令牌？没令牌请求过来不就直接拒了么？这就误杀了，明明系统没啥负载现在。
    • 再比如说请求的访问其实是随机的，假设令牌桶每20ms放入一个令牌，桶内初始没令牌，这请求就刚好在第一个20ms内有两个请求，再过20ms里面没请求，其实从40ms来看只有2个请求，应该都放行的，而有一个请求就直接被拒了。
    • 这就有可能造成很多请求的误杀，但是如果看监控曲线的话，好像流量很平滑，峰值也控制的很好。
  • 再拿漏桶来说，漏桶中请求是暂时存在桶内的，这其实不符合互联网业务低延迟的要求。

限流组件

一般而言，我们不需要自己实现限流算法来达到限流的目的，不管是接入层限流还是细粒度的接口限流，都有现成的轮子使用，其实现也是用了上述我们所说的限流算法。

  • Google Guava 提供的限流工具类 RateLimiter，是基于令牌桶实现的，并且扩展了算法，支持预热功能。
  • 阿里开源的限流框架Sentinel 中的匀速排队限流策略，就采用了漏桶算法。
  • Nginx 中的限流模块 limit_req_zone，采用了漏桶算法。
  • OpenResty 中的 resty.limit.req库等等。

单机 & 分布式

本质上单机限流和分布式限流的区别其实就在于 “阈值” 存放的位置。

单机限流就上面所说的算法直接在单台服务器上实现就好了，而往往我们的服务是集群部署的。
因此需要多台机器协同提供限流功能。

单机限流

应用级限流方式只是单应用内的请求限流，不能进行全局限流。

  • 限流总资源数
  • 限流总并发/连接/请求数
  • 限流某个接口的总并发/请求数
  • 限流某个接口的时间窗请求数
  • 平滑限流某个接口的请求数
  • Guava RateLimiter

分布式限流

我们需要分布式限流和接入层限流来进行全局限流。

  • redis+lua实现中的lua脚本
  • 使用Nginx+Lua实现的Lua脚本
  • 使用 OpenResty 开源的限流方案
  • 限流框架，比如Sentinel实现降级限流熔断