限速脚本_限速

限速脚本

Protecting APIs from overuse by limiting how often users can access them, comes with it, several benefits. It helps against denial-of-service attacks, brute-force login attempts, and other types of abusive behaviour targeting the application layer.

通过限制用户访问API的频率来保护API避免过度使用，它具有许多好处。 它有助于抵御拒绝服务攻击，暴力登录尝试以及针对应用层的其他类型的滥用行为。

The purpose of this post is to provide a short and concise overview of the various types of rate limiting algorithms.

这篇文章的目的是简要概述各种类型的速率限制算法。

A little knowledge of Redis is required to fully grasp this post.

要完全掌握此职位，需要对Redis有所了解。

限速器类型 (Types of Rate Limiter)

• User rate limiter: This allows certain user limited access to an API. Number/duration of requests users make are usually tied to their userIds, API keys or IP addresses.

  用户速率限制器 ：这允许某些用户受限地访问API。 用户发出的请求的数量/持续时间通常与他们的userIds ，API密钥或IP地址相关。

• Concurrent/server rate limiter: This tracks how many parallel session or connection is allowed for a certain user. It mitigates DDoS attacks.

  并发/服务器速率限制器 ：这跟踪特定用户允许多少个并行会话或连接。 它减轻了DDoS攻击。

• Location rate limiter: Rate limits can be set for particular regions and also for a particular time period. If users in location A are more active than users in location B for a specific time of each day, you can define lower rate limits for users in location A for that period of time.

  位置速率限制器 ：可以为特定区域和特定时间段设置速率限制。 如果每天在特定时间段内位置A的用户比位置B的用户更活跃，则可以为该时间段内位置A的用户定义较低的速率限制。

速率限制器算法 (Rate Limiter Algorithms)

• Token Bucket
  令牌桶
• Leaky Bucket
  漏斗
• Fixed Window Counter
  固定窗口计数器
• Sliding Logs
  滑动日志
• Sliding Window Counter
  推拉窗柜台

令牌桶 (Token Bucket)

This is the simplest rate limiter algorithm. We simply keep track of the number of requests made within a set time interval.

这是最简单的速率限制器算法。 我们只需跟踪在设定的时间间隔内发出的请求数即可。

Using Redis as the bucket, let’s design a “5 requests/min” rate limiter.

使用Redis作为 我们为此设计一个“ 5个请求/分钟”的速率限制器。

For every new unique user request, we’d create a hash key entry on the userId, containing the request timestamp and a token count set to 5.

对于每个新的唯一用户请求，我们将在userId上创建一个哈希键条目，其中包含请求时间戳和设置为5的令牌计数。

For subsequent requests, we’d fetch the equivalent hash for that particular userId, and update it with the current request timestamp and the available token count left. If a user exhausts the 5 tokens within the same minute window from his first request, all other requests from that user would be dropped.

对于后续请求，我们将获取该特定userId的等效哈希 ，并使用当前请求时间戳和剩余的可用令牌计数对其进行更新。 如果用户在第一个请求的同一分钟窗口内用尽了5令牌，则该用户的所有其他请求将被丢弃。

The tokens are reset to the original count when the rate limit time interval elapses.

当速率限制时间间隔过去时，令牌将重置为原始计数。

Caveat: For the Redis implementation above, the operations are not atomic due to the “read-and-then-write” behaviour, thus in a distributed environment, we could have a race condition issue.

注意 ：对于上面的Redis实现，由于“先读后写 ”的行为，操作不是原子的，因此在分布式环境中，我们可能会遇到竞争条件问题。

漏斗 (Leaky Bucket)

A simple leaky bucket algorithm can be implemented using a FIFO queue implementation. It translates requests into a First In First Out format, processing the items on the queue at a regular rate.

可以使用FIFO队列实现来实现简单的漏斗算法。 它将请求转换为先进先出格式，以规则的速率处理队列中的项目。

The figure below shows a bucket that is processing four requests at a time.

下图显示了一个桶 ，一次处理四个请求。

We can only serve N requests at any given time, where N is the queue size.

我们只能在任何给定时间服务N个请求，其中N是队列大小。

Leaky Bucket smoothens outbursts of traffic, and it’s easy to implement on a single server or load balancer.

Leaky Bucket可以缓解流量突增，并且很容易在单个服务器或负载均衡器上实现。

固定窗口计数器 (Fixed Window Counter)

In a fixed window algorithm, a window size, N, is used to track the request rate. The window is defined on a set number — which an incremental counter counts towards. If the counter exceeds the set limit, all additional requests will be dropped.

在固定窗口算法中，窗口大小N用于跟踪请求率。 窗口是在设定的编号上定义的-增量计数器将计入该编号。 如果计数器超过设置的限制，则所有其他请求将被丢弃。

We can also use Redis for the implementation, and unlike the token bucket algorithm, its operations are atomic. Each request would increment a Redis key that includes the request’s timestamp.

我们也可以使用Redis来实现，与令牌桶算法不同，它的操作是原子的。 每个请求都会增加一个包含请求时间戳的Redis密钥。

This approach is memory efficient as we don’t update the Redis key till the next minute — for a minute based rate limiter.

这种方法可提高内存效率，因为我们要等到下一分钟才更新Redis密钥- 基于分钟的速率限制器。

Although there could be a problem: Fix Window Counter could allow twice as many requests over the rate limit interval.

尽管可能存在问题： 修复窗口计数器可以在速率限制间隔内允许两倍的请求。

For a “10 requests/min” rate limiter, if a user made 10 requests at 5:00:59, they could make an additional 10 requests more at 5:01:00. Because a new counter begins at the start of each minute, we’ve now allowed 20 requests in less than one minute.

对于“10个请求/分钟”速率限制，如果用户做出10个请求5:00:59 ，他们可以使一个额外的10请求更多的在5:01:00 。 由于每分钟开始时都会有一个新计数器开始，因此我们现在在一分钟之内就允许了20请求。

There are several complicated workarounds to fix this, but it overcomplicates the algorithm.

有几种复杂的解决方法可以解决此问题，但是会使算法过于复杂。

滑动日志 (Sliding Log)

This algorithm solves the Fixed Window double request count issue, by calculating the request rate in real-time — instead of calculating it in each request window, as described above.

此算法解决了固定窗口重复请求计数问题， 通过实时计算请求率-而不是如上所述在每个请求窗口中计算请求率。

A sliding log algorithm tracks every request via a timestamped log, in a single sorted set. For every new request, we need to access the logs and filter out entries older than one minute — for a minute based rate limiter.

滑动日志算法通过带时间戳的日志在单个排序集中跟踪每个请求。 对于每个新请求，我们都需要访问日志并筛选出超过一分钟的条目- 基于分钟的速率限制器。

When a new request is processed, the sum of the log entries for that unique user is calculated to determine the request rate. Logs with timestamps that exceed the rate limit are discarded. If the request count exceeds the threshold, they are also discarded.

处理新请求时，将计算该唯一用户的日志条目的总和以确定请求率。 时间戳超过速率限制的日志将被丢弃。 如果请求计数超过阈值，它们也会被丢弃。

Sliding log algorithms don’t suffer from the stampeding issues of Fixed Windows. Although it can get quite expensive to store loads of logs for each request, and calculating the number of requests across multiple servers can also be expensive.

滑动日志算法不会受到固定Windows标记问题的影响。 尽管为每个请求存储日志负载可能会变得非常昂贵，但跨多个服务器计算请求数也会很昂贵。

Sliding log algorithms aren’t the best for scalable APIs that prevent overload, or DoS attacks.

对于可避免过载或DoS攻击的可扩展API而言，滑动日志算法并不是最佳选择。

推拉窗柜台 (Sliding Window Counter)

Sliding window algorithms combine both Fixed Window and Sliding Log algorithms.

滑动窗口算法结合了固定窗口算法和滑动日志算法。

Here the window time is broken down into smaller buckets — and the size of each bucket depends on the rate-limit threshold. Each bucket stores the request count corresponding to the bucket range, which constantly keeps moving across time, while smoothing outbursts of traffic.

在这里， 窗口时间可细分为较小的存储桶-每个存储桶的大小取决于速率限制阈值。 每个存储桶都存储与该存储桶范围相对应的请求计数， 它会随着时间的推移不断变化 ，同时使交通流量更加畅通。

Let depicts a sliding windows counter for a “5 requests/min” rate limiter, using each second as the window.

设描绘了滑动窗口为“5个请求/分钟”的速率限制器计数器，使用每个第二作为窗口。

5 requests/min rate limiter 5个请求/分钟的速率限制器

From the figure above, user_1 made a new request which creates a Redis entry with the request time, 9:01:01, as its hash key with a counter set to 1 — for the _:_:01–second window.

从上图中，USER_1制成其产生与所述请求的时间，一个Redis的条目的新请求9:01:01 ，与一个计数器设置为它的散列密钥 1 -为对_:_:01 - 第二窗口。

The user didn’t make any more requests until the _:_:02–second window, where he makes 4 more requests, as described in the figure above, thus maxing out the “5 requests/min” limit for the _:01:_ to _:02:_ one-minute interval. All other requests for that interval would be dropped, till the start of a new window: _:03:_.

用户直到第二个窗口_:_:02发出更多请求，如上图所示，在该窗口中又发出了4个请求，从而使_:01:_的“ 5个请求/分钟”限制最大化_:01:_ 至 _:02:_ 一分钟的间隔。 在该时间间隔内的所有其他请求将被删除，直到一个新窗口开始： _:03:_ 。

That’s all for now.

目前为止就这样了。

翻译自: https://medium.com/kudi-engineering/rate-limiting-fdf15bfe84ab

限速脚本