ByteByteGo学习笔记：设计限流器

在现代应用系统中，限流器（Rate Limiter）是一种至关重要的工具，用于控制客户端对服务的请求速率。

限流器的基本概念

限流器的核心功能是限制在特定时间内可以发送的请求数量。在HTTP世界中，限流器通过定义阈值来控制请求流量。以下是一些常见的限流规则：

• 用户每秒最多可以发布2条推文。
• 每天最多可以创建10个账户，且这些账户必须来自不同的IP地址。
• 每周最多可以从同一设备领取5次奖励。

设计限流器的好处

• 防止资源耗尽：通过拒绝服务（DoS）攻击可以导致资源耗尽，几乎所有大型科技公司都会实施某种形式的限流。例如，Twitter限制用户每3小时最多发布300条推文。
• 降低成本：限制过多的请求意味着更少的服务器和更多的资源分配给高优先级的API。这对于使用第三方API的公司尤为重要。
• 防止服务器过载：通过减少服务器负载，限流器可以过滤掉由机器人或用户错误行为引起的过多请求。

设计范围

在设计限流器时，需要明确其类型（构建的限流器是客户端还是服务器端API限流器）。以下是一些关键问题需要考虑：

• 限流器是否根据IP地址、用户ID或其他属性来限制API请求？
• 限流器是否足够灵活以支持不同的限制规则？
• 系统是否能够处理大量请求？
• 系统是否在分布式环境中工作？
• 限流器是作为一个独立服务还是应用代码中实现？

系统要求

限流器系统需要满足以下要求：

• 准确限制过多请求。
• 低延迟，限流器不应减慢HTTP响应时间。
• 尽可能少地使用内存。
• 分布式限流，限流器可以在多个服务器或进程之间共享。
• 异常处理，当请求被限制时，向用户提供明确的异常信息。
• 高容错性，例如，缓存服务器宕机时，不会影响整个系统。

高层次设计

为了简化设计，使用基本的客户端和服务器模型进行通信。以下是两种常见的实现方式：

• 客户端实现：通常，客户端不是一个可靠的实现位置，因为客户端请求可以被恶意行为者伪造，而且我们可能无法控制客户端实现。
• 服务器端实现：限流器位于服务器端。
  
  除了客户端和服务器端实现，还有一种替代方案，即在API服务器之间创建一个限流中间件。
  

微服务中的限流

微服务已经成为广泛流行的架构，限流通常在称为API网关的组件中实现。API网关是一个完全托管的服务，支持限流、终止、身份验证、IP白名单、静态内容服务等。API网关作为支持限流的中间件。

限流器的实现位置

在设计限流器时，需要考虑其实现位置。以下是一些指导原则：

• 评估当前技术栈，确保编程语言能够高效实现限流。
• 确定适合业务需求的限流算法，并在服务器端实现。
• 如果已经使用微服务架构并在设计中包含API网关，可以在API网关中添加限流器。
• 如果有足够的资源，可以自己构建限流器；否则，商业API网关可能是更好的选择。

限流算法

1.令牌桶算法

• 原理：令牌桶算法通过一个固定容量的桶来存储令牌，令牌以固定速率添加到桶中。每个请求消耗一个令牌，如果桶中没有足够的令牌，请求将被拒绝。

• 优点：

  • 算法简单易懂，易于实现。
  • 内存效率高，因为只需要存储令牌和桶的大小。
  • 允许短时间内的流量突发，因为桶中可以积累令牌。

• 缺点：

  • 参数调整（桶大小和令牌补充速率）可能具有挑战性，需要根据具体需求进行调优。

• 适用场景：

  • 适用于需要灵活处理请求突发的场景。
  • 适用于分布式系统，可以在多个服务器之间共享令牌桶。

2.漏桶算法

• 原理：漏桶算法以固定速率处理请求，通常使用先进先出（FIFO）队列实现。请求按固定速率从桶中流出，如果桶满了，新的请求将被丢弃。

• 优点：

  • 内存效率较高，因为只需要存储请求队列。
  • 请求以固定速率处理，适合稳定输出速率的场景。

• 缺点：

  • 有两个参数（桶大小和输出速率），可能不易调优。
  • 不允许流量突发，因为请求必须按固定速率处理。

• 适用场景：

  • 适用于需要稳定输出速率的场景。
  • 适用于电子商务公司，需要控制请求处理速率。

3.固定窗口计数器

• 原理：将时间划分为固定大小的窗口，并为每个窗口分配一个计数器。每个请求增加计数器，如果计数器达到预定义阈值，新请求将被丢弃。

• 优点：

  • 内存效率高，因为只需要存储计数器。
  • 易于理解，实现简单。

• 缺点：

  • 在窗口边缘可能出现流量突发问题，因为计数器在每个窗口开始时重置。

• 适用场景：

  • 适用于简单场景，不需要复杂的流量控制。
  • 适用于对流量突发不敏感的场景。

4.滑动窗口计数器

• 原理：结合固定窗口计数器和滑动窗口日志，维护请求时间戳的有序集合。新请求到来时，移除过时的时间戳，如果请求数量超过阈值，请求将被拒绝。

• 优点：

  • 非常准确，不会超过速率限制。
  • 适用于任何滚动窗口场景。

• 缺点：

  • 消耗大量内存，因为即使请求被拒绝，时间戳仍需存储在内存中。

• 适用场景：

  • 适用于需要高精度控制的场景。
  • 适用于对流量控制要求严格的场景。

高层次架构

限流器的基本思想很简单：需要一个计数器来跟踪来自同一用户、IP地址等的请求数量。如果计数器超过限制，请求将被禁用。计数器可以存储在内存缓存中，如Redis。

客户端发送请求到限流中间件，中间件从Redis中获取计数器并检查是否达到限制。如果达到限制，请求将被拒绝；否则，请求将被发送到API服务器。

限流规则

Lyft开源了他们的限流组件，提供了一些限流规则的例子。以下是一些常见的规则：

domain: messaging
descriptors:
  - key: message_type
    value: marketing
    rate_limit:
      unit: day
      requests_per_unit: 5

这些规则通常写在配置文件中并保存在磁盘上。

超出限流

如果请求超出限流，API将返回HTTP响应代码429（请求过多）。根据用例，可能会将请求排队以供后续处理。
限流器头部
当用户请求过多时，限流器会返回以下HTTP头部：

• X-Ratelimit-Remaining：窗口内剩余的允许请求数。
• X-Ratelimit-Limit：窗口内允许的请求数。
• X-Ratelimit-Retry-After：等待多少秒后可以再次请求。

详细设计

规则存储在磁盘上，工作线程频繁从磁盘拉取规则并存储在缓存中。当客户端发送请求到服务器时，请求首先发送到限流中间件。中间件从缓存中加载规则，并根据响应决定请求是否被转发到API服务器。

分布式环境中的限流器

在分布式环境中构建限流器并不困难，但需要解决两个挑战：竞态条件和同步问题。

竞态条件

在高并发环境中，多个请求可能同时读取和增加计数器，导致不正确的结果。解决竞态条件的常见策略包括使用锁和Lua脚本。

同步问题

在分布式环境中，需要同步多个限流服务器的数据。可以使用集中式数据存储如Redis来解决同步问题。

性能优化

对于限流器，主要关注两个方面：

• 多数据中心设置：由于延迟问题，大多数云服务提供商在全球范围内建立多个边缘服务器位置。流量自动路由到最近的边缘服务器以减少延迟。

• 使用最终一致性模型同步数据：如果对最终一致性模型不熟悉，可以参考“设计键值存储”章节。

  监控

  在限流器部署后，收集分析数据以检查其有效性非常重要。主要检查以下几点：

• 限流算法是否有效。
• 限流规则是否有效。

这篇学习笔记详细记录了设计和实现限流器的各个方面，从基本概念到高级架构，涵盖了关键知识点和重要数据。希望这些内容能够帮助你更好地理解和应用限流器。

参考资料
ByteByteGo