系统访问限流算法介绍（简单的业务复杂的脑袋）

系统访问限流算法介绍
转载自：https://zhuanlan.zhihu.com/p/497173442
最近遇到系统个别业务集中访问的情况，遂到网上求助各路大神，之后稍一查看就在知乎问答找到这一篇系统限流算法。查看之后对我的问题处理有很大帮助，结合业务我选了令牌桶这一算法，在次备案（留作以后总结😊）。限流方法不止这些，有更多方法欢迎推荐。
令牌桶算法
令牌桶（token bucket）算法，指的是设计一个容器（即“桶”），由某个组件持续运行往该容器中添加令牌（token），令牌可以是简单的数字、字符或组合，也可以仅仅是一个计数，然后每个请求进入系统时，需要从桶中领取一个令牌，所有请求都必须有令牌才能进入后端系统。当令牌桶空时，拒绝请求；当令牌桶满时，不再往其中添加新的令牌。
令牌桶算法的架构如图1所示：

图1 令牌桶算法
令牌桶算法的实现逻辑如下：
首先会有一个定义的时间窗口的访问次数阈值，例如每天1000人，每秒5个请求之类，限流系统一般最小粒度是秒，再小就会因为实现和性能的原因而变得不准确或不稳定，假设是T秒内允许N个请求，那么令牌桶算法则会使令牌添加组件每T秒往令牌桶中添加N个令牌。
其次，令牌桶需要有一个最大值M，当令牌添加组件检测到令牌桶中已经有M个令牌时，剩余的令牌会被丢弃。

反映到限流系统中，可以认为是当前系统允许的瞬时最大流量，但不是持续最大流量。例如令牌桶中的令牌最大数量是100个，每秒钟会往其中添加10个新令牌，当令牌满的时候，突然出现100 TPS的流量，这时候是可以承受的，但是假如连续两秒的100 TPS流量就不行，因为令牌添加速度是一秒10个，添加速度跟不上使用速度。
因此，凡是使用令牌桶算法的限流系统，我们都会注意到它在配置时要求两个参数：

平均阈值（rate或average）
高峰阈值（burst或peak）

通过笔者的介绍，读者应该意识到，令牌桶算法的高峰阈值是有特指的，并不是指当前限流系统允许的最高流量。因为这一描述可能会使人认为只要低于该阈值的流量都可以，但事实上不是这样，因为只要高于添加速度的流量持续一段时间都会出现问题。
反过来说，令牌桶算法的限流系统不容易计算出它支持的最高流量，因为它能实时支持的最高流量取决于那整个时间段内的流量变化情况即令牌存量，而不是仅仅取决于一个瞬时的令牌量。

最后，当有组件请求令牌的时候，令牌桶会随机挑选一个令牌分发出去，然后将该令牌从桶中移除。注意，此时令牌桶不再做别的操作，令牌桶永远不会主动要求令牌添加组件补充新的令牌。
令牌桶算法有一个同一思想、方向相反的变种，被称为漏桶（leaky bucket）算法，它是令牌桶的一种改进，在商业应用中非常广泛。
漏桶算法的基本思想，是将请求看作水流，用一个底下有洞的桶盛装，底下的洞漏出水的速率是恒定的，所有请求进入系统的时候都会先进入这个桶，并慢慢由桶流出交给后台服务。桶有一个固定大小，当水流量超过这个大小的时候，多余的请求都会被丢弃。
漏桶算法的架构如图2所示：

图2 漏桶算法
漏桶算法的实现逻辑如下：

首先会有一个容器存放请求，该容器有一个固定大小M，所有请求都会被先存放到该容器中。
该容器会有一个转发逻辑，该转发以每T秒N个请求的速率循环发生。
当容器中请求数已经达到M个时，拒绝所有新的请求。

因此同样地，漏桶算法的配置也需要两个值：平均值（rate）和峰值（burst）。只是平均值这时候是用来表示漏出的请求数量，峰值则是表示桶中可以存放的请求数量。
注意：漏桶算法和缓冲的限流思想不是一回事！
同样是将请求放在一个容器中，漏桶算法和缓冲不是一个用途，切不可搞混，它们的区别如下：

漏桶算法中，存在桶中的请求会以恒定的速率被漏给后端业务服务器，而缓冲思想中，放在缓冲区域的请求只有等到后端服务器空闲下来了，才会被发出去。
漏桶算法中，存在桶中的请求是原本就应该被系统处理的，是系统对外界宣称的预期，不应该被丢失，而缓冲思想中放在缓冲区域的请求仅仅是对意外状况的尽量优化，并没有任何强制要求这些请求可以被处理。

漏桶算法和令牌桶算法在思想上非常接近，而实现方向恰好相反，它们有如下的相同和不同之处：

令牌桶算法以固定速率补充可以转发的请求数量（令牌），而漏桶算法以固定速率转发请求；
令牌桶算法限制数量的是预算数，漏桶算法限制数量的是实际请求数；
令牌桶算法在有爆发式增长的流量时可以一定程度上接受，漏桶算法也是，但当流量爆发时，令牌桶算法会使业务服务器直接承担这种流量，而漏桶算法的业务服务器感受到的是一样的速率变化。

因此，通过以上比较，我们会发现漏桶算法略优于令牌桶算法，因为漏桶算法对流量控制更平滑，而令牌桶算法在设置的数值范围内，会将流量波动忠实地转嫁到业务服务器头上。
漏桶算法在Nginx和分布式的限流系统例如Redis的限流功能中都有广泛应用，是目前业界最流行的算法之一。

时间窗口算法
时间窗口算法是比较简单、基础的限流算法，由于它比较粗略，不适合大型、流量波动大或者有更精细的流量控制需求的网站。
时间窗口算法根据确定时间窗口的方式，可以分为两种：

固定时间窗口算法
滑动时间窗口算法

固定时间窗口算法最简单，相信如果让初次接触限流理念的读者去快速设计实现一个限流系统的话，也可以很快想到这种算法。这种算法即固定一个时间段内限定一个请求阈值，没有达到则让请求通过，达到数量阈值了就拒绝请求。步骤如下：

先确定一个起始时间点，一般就是系统启动的时间。
从起始时间点开始，根据我们的需求，设置一个最大值M，开始接受请求并从0开始为请求计数。
在时间段T内，请求计数超过M时，拒绝所有剩下的请求。
超过时间段T后，重置计数。

固定时间窗口算法的思路固然简单，但是它的逻辑是有问题的，它不适合流量波动大和有精细控制流量需求的服务。让我们看以下例子：
假设我们的时间段T是1秒，请求最大值是10，在第一秒内，请求数量分布是第500毫秒时有1个请求，第800毫秒时有9个请求，如图3所示：

图3 固定时间窗口限流第一秒的请求分布
这是对于第一秒而言，这个请求分布是合理的。
此时第二秒的第200毫秒（即两秒中的第1200毫秒）内，又来了10个请求，如图4所示：

图4 固定时间窗口限流第二秒的请求分布
单独看第二秒依然是合理的，但是两个时间段连在一起的时候，就出现了问题，如图5所示：

图5 固定时间窗口限流的头两秒请求分布
从500毫秒到1200毫秒，短短700毫秒的时间内后端服务器就接收了20个请求，这显然违背了一开始我们希望1秒最多10个的初衷。这种远远大于预期流量的流量加到后端服务器头上，是会造成不可预料的后果的。因此，人们改进了固定窗口的算法，将其改为检查任何一个时间段都不超过请求数量阈值的时间窗口算法：滑动时间窗口算法。
滑动时间窗口算法要求当请求进入系统时，回溯过去的时间段T，找到其中的请求数量，然后决定是否接受当前请求，因此，滑动时间窗口算法需要记录时间段T内请求到达的时间点，逻辑如图6所示：

图6 滑动时间窗口限流系统的逻辑
解释如下：
1、确定一个起始时间点，一般就是系统启动的时间，并记录该点为时间窗口的开始点。然后创建一个空的列表作为时间窗口内请求进入的时间戳记录。
2、当请求到来时，使用当前时间戳比较它是否在时间窗口起始点加上T时间段（从开始点到开始点+T就是时间窗口）内。

如果在，则查看当前时间窗口内记录的所有请求的数量：
如果超过，则拒绝请求。如果没有，则将该请求加入到时间戳记录中，并将请求交给后端业务服务器。
如果不在，则查看时间戳记录，将时间戳最久远的记录删除，然后将时间窗口的开始点更新为第二久远的记录时间，然后回到步骤2，再次检查时间戳是否在时间窗口内。

滑动时间窗口尽管有所改进，但依然不能很好应对某个时间段内突发大量请求，而令牌桶和漏桶算法就由于允许指定平均请求率和最大瞬时请求率，它比时间窗口算法控制更精确。
时间窗口算法可以通过多时间窗口来改进。例如，可以设置一个1秒10 TPS的时间窗口限流和一个500毫秒5 TPS的时间窗口限流，二者同时运行，如此就可以保证更精确的限流控制。

队列法

队列法与漏桶算法很类似，都是将请求放入到一个区域，然后业务服务器从中提取请求，但是队列法采用的是完全独立的外部系统，而不是依附于限流系统。队列法的架构如图7所示：

图7 使用队列限流的架构
与漏桶算法相比，队列法的优势如下：

由业务逻辑层决定请求收取的速度。限流系统即队列不需要再关注流量的设置（例如T是多少，N是多少，M又是多少等等），只需要专注保留发送的请求，而业务服务器由于完全掌控消息的拉取，可以根据自身条件决定请求获取的速度，更加自由。
完全将业务逻辑层保护起来，并且可以增加服务去消费这些请求。这一手段将业务服务器完全隐藏在了客户端后面，由队列去承担所有流量，也可以更好地保护自身不受到恶意流量的攻击。
队列可以使用更健壮、更成熟的服务，这些服务比限流系统复杂，但能够承受大得多的流量。例如，业务服务器使用的是像阿里云或者AWS这样的消息队列的话，业务服务器就不用担心扩容的问题了，只要请求对实时性的要求不高。业务服务器由于使用了云服务，队列一端的扩容不用担心，而由于消息是自由决定拉取频率和处理速度，自身的扩容压力也就不那么大了。

但队列法最大的缺陷，就是服务器不能直接与客户端沟通，因此只适用于客户端令业务服务器执行任务且不要求响应的用例，所有客户端需要有实质响应的服务都不能使用。例如，业务服务器提供的服务是消息发送服务，那么这种模式就可以的，但如果客户端是请求某些用户信息，那这种方式就完全不可行了。

（后边的图就不加了，毕竟人比较懒）
分布式系统中的限流器实现算法

一般限流器有五种算法，分别是：令牌桶，漏斗桶，固定窗口，滑动日志（指的其实是广义上的滑动窗口），滑动窗口（这里指的是滑动日志+固定窗口结合的一种算法）。

令牌桶（Token bucket）

令牌桶算法用来控制一段时间内发送到网络上的数据的数目，并允许突发数据的发送。

算法大概是： 假设允许的请求速率为r次每秒，那么每过1/r秒就会向桶里面添加一个令牌。桶的最大大小是b。当一个大小为n的请求到来时，检查桶内令牌数是否足够，如果足够，令牌数减少n，请求通过。不够的话就会触发拒绝策略。
令牌桶有一个固定大小，假设每一个请求也有一个大小，当要检查请求是否符合定义的限制时，会检查桶，以确定它当时是否包含足够的令牌。

如果有，那么会移除掉这些令牌，请求通过。否则，会采取其他操作，一般是拒绝。令牌桶中的令牌会以一定速率恢复，这个速率就是允许请求的速率（当然，根据大小的配置，可能实际会超过这个速率，但是随着令牌桶的消耗会被调整回这个恢复速率）。
如果令牌不被消耗，或者被消耗的速度小于产生的速度，令牌就会不断地增多，直到把桶填满。可以看出，令牌桶在保持整体上的请求速率的同时，允许某种程度的突发传输。
分布式环境下的令牌桶的实现需要考虑如下几个问题：

令牌桶当前大小究竟如何存储？是只存储一个当前令牌桶的大小（例如通过 redis 的一个键值对存储），还是存放每个通过的请求到来的时间戳（例如通过 redis 的 zset 实现，zset 的大小就是桶的最大大小）？
令牌桶的令牌补充是由谁补充？对于存储一个当前令牌桶的大小的实现方式，需要一个进程以速率r不断地往里面添加令牌，那么如何在分布式的环境下保证有且只有一个这样的进程，这个进程挂了怎么办？对于存放每个通过的请求到来的时间戳的这种实现方式实现，那么怎么控制记录请求的个数，肯定不能每个都记录，并且每次怎么通过目前的请求以及时间戳来判断剩余令牌数量

漏斗桶（Leaky bucket）

漏斗桶控制请求必须在最大某个速率被消费，就像一个漏斗一样，入水量可大可小，但是最大速率只能到某一量值，不会像令牌桶一样，会有小的尖峰。

算法大概是： 主要实现方式是通过一个 FIFO （First in first out）的队列实现，这个队列是一个有界队列，大小为b，如果请求堆积满了队列，就会触发丢弃策略。假设允许的请求速率为r次每秒，那么这个队列中的请求，就会以这个速率进行消费。
分布式环境下的漏桶的实现需要考虑如下几个问题：

漏桶的队列，怎么存放？这个队列需要存放每个通过的请求以及对应的消费的时间戳，保证消费的平稳。同时，这个队列最好是无锁队列，因为会有分布式锁征用。并且，这个队列大小应该设置为b，并每次有请求到来时，放入队列的同时清理队列。
消费如何实现？也就是存入队列的请求，如何消费呢？可以请求到来时，通过队列中的请求来判断当前这个请求的执行时间应该是多久以后，之后入队列，延迟这么久再执行这个请求。也可以利用本身带延迟时间实现的队列来实现。
固定时间窗口（Fixed window）

固定时间窗口比较简单，就是将时间切分成若干个时间片，每个时间片内固定处理若干个请求。这种实现不是非常严谨，但是由于实现简单，适用于一些要求不严格的场景。 算法大概是： 假设n秒内最多处理b个请求，那么每隔n秒将计数器重置为b。请求到来时，如果计数器值足够，则扣除并请求通过，不够则触发拒绝策略。

固定时间窗口是最容易实现的算法，但是也是有明显的缺陷：那就是在很多情况下，尤其是请求限流后拒绝策略为排队的情况下，请求都在时间窗口的开头被迅速消耗，剩下的时间不处理任何请求，这是不太可取的。并且，在一些极限情况下，实际上的流量速度可能达到限流的 2 倍。例如限制 1 秒内最多 100 个请求。假设 0.99 秒的时候 100 个请求到了，之后 1.01 秒的时候又有 100 个请求到了，这样的话其实在 0.99 秒 ~ 1.01 秒这一段时间内有 200 个请求，并不是严格意义上的每一秒都只处理 100 个请求。为了能实现严格意义上的请求限流，则有了后面两种算法。

滑动日志（Sliding Log）

滑动日志根据缓存之前接受请求对应的时间戳，与当前请求的时间戳进行计算，控制速率。这样可以严格限制请求速率。一般的网上提到的滑动窗口算法也指的是这里的滑动日志（Sliding Log）算法，但是我们这里的滑动窗口是另一种优化的算法，待会会提到。

算法大概是： 假设n秒内最多处理b个请求。那么会最多缓存 b 个通过的请求与对应的时间戳，假设这个缓存集合为B。每当有请求到来时，从B中删除掉n秒前的所有请求，查看集合是否满了，如果没满，则通过请求，并放入集合，如果满了就触发拒绝策略。
分布式环境下的滑动日志的实现需要考虑如下几个问题：

我们的算法其实已经简化了存储，但是对于高并发的场景，要缓存的请求可能会很多（例如限制每秒十万的请求，那么这个缓存的大小是否就应该能存储十万个请求？），这个缓存应该如何实现？
高并发场景下，对于这个集合的删除掉n秒前的所有请求的这个操作，需要速度非常快。如果你的缓存集合实现对于按照时间戳删除这个操作比较慢，可以缓存多一点请求，定时清理删除n秒前的所有请求而不是每次请求到来都删除。请求到来的时候，查看b个之前的请求是否存在并且时间差小于n秒，存在并且小于代表应该触发限流策略。
滑动窗口（滑动日志 + 固定窗口）

前面的滑动日志，我们提到了一个问题 - 要缓存的请求可能会很多。也许在我们的架构内不能使用一个恰当的缓存来实现，我们可以通过滑动窗口这个方法来减少要存储的请求数量，并减少集合大小减少同一个集合上面的并发。

算法大概是： 假设n秒内最多处理b个请求。我们可以将n秒切分成每个大小为m毫秒得时间片，只有最新的时间片内缓存请求和时间戳，之前的时间片内只保留一个请求量的数字。这样可以大大优化存储，小幅度增加计算量。对于临界条件，就是之前已经有了n/m个时间片，计算n秒内请求量时可以计算当前时间片内经过时间的百分比，假设是 25%，那么就取开头的第一个时间片的请求量的 75% 进行计算。