从令牌桶到滑动窗口：选择最合适的限流算法

核心要点

• 限流 是一种控制用户或客户端访问 API 或服务速率的关键机制。
• 其主要意义在于防止滥用、确保系统稳定性，并在用户间维持公平的资源分配。
• 限流器 是执行这些预定义限制的组件，充当传入请求的守门员。
• 理解各种限流算法，如固定窗口、漏桶，尤其是滑动窗口和限流，对于有效实施至关重要。
• 正确的限流有助于缓解诸如拒绝服务攻击、暴力破解尝试和资源耗尽等风险，防止合法用户遭遇 API 速率限制超出 错误，并确保你的服务不会因限流而变得无响应。

什么是限流？定义概念

在现代广阔的 Web 服务领域中，API（应用程序编程接口）是连接性的基石。它们促进了不同软件系统之间的通信，支持从移动应用到复杂的微服务架构的一切。然而，这种开放的访问方式虽然强大，也带来了显著的漏洞：滥用。如果单个客户端每秒向你的 API 发送数百万个请求怎么办？或者恶意攻击者试图暴力破解用户凭据？如果没有适当的控制，此类情况很快就会导致服务降级、中断甚至安全漏洞。

这就是限流发挥作用的地方。其核心在于，限流是一种防御机制，旨在控制客户端在指定时间范围内向服务器或 API 发出请求的频率。限流的意义很直接：它为特定操作的执行频率设定了边界。可以把它想象成热门俱乐部的保镖，确保场地不会过度拥挤，里面的每个人都能获得良好体验。

负责执行这些规则的组件称为限流器。这个限流器拦截传入的请求，根据预定义的规则（例如，每个 IP 地址每分钟 100 个请求）进行检查，并决定是允许请求继续还是阻止它。其主要目的是保护你的基础设施免受过载影响，防止恶意活动，并确保所有用户之间的资源公平分配。

为什么要实施限流？好处

实施限流不仅仅是一项技术配置；对于任何健壮且可扩展的 API 来说，它都是一项战略要务。其好处远不止防止简单的过载：

• 保护基础设施免受过载并确保服务可用性： 如果没有限流，无论是意外还是恶意（如分布式拒绝服务 - DDoS 攻击）导致的请求突然激增，都可能压垮你的服务器、数据库和其他后端资源。这会导致响应时间变慢、出错，并最终导致服务不可用。限流充当了关键的缓冲区，在过载拖垮系统之前将其分流，从而为合法用户确保持续的服务可用性。这是为你的 API 维持一个稳定的限制速率。

• 防止恶意活动：

  • DDoS 攻击： 恶意行为者用请求淹没你的 API 以使其不可用。限流可以检测并阻止这些高流量、可疑的模式。
  • 暴力破解攻击： 通过进行大量登录尝试来猜测密码或 API 密钥。在身份验证端点上进行限流可以显著减慢或完全阻止此类攻击。
  • 数据抓取： 不道德的实体可能会尝试从你的 API 快速提取大量数据。限流使这一过程变得缓慢且效率低下，从而阻止此类活动。

• 确保公平的资源使用： 在多租户环境或公共 API 中，某些用户可能会无意（或有意）地消耗不成比例的资源份额，从而影响其他用户。限流确保没有单个客户端垄断你的 API，保证每个人都能获得合理水平的服务。这防止了合法用户仅仅因为另一个用户过于激进而面临 API 速率限制超出 错误的情况。

• 成本优化： 对于按计算、带宽或数据库操作付费的云服务，不受控制的 API 访问可能导致意外的高额账单。通过控制请求量，限流有助于管理和优化运营成本。

• 改善用户体验： 虽然看起来可能有些矛盾，但偶尔阻止一些过多的请求可以为大多数用户带来更好的整体体验。通过保持系统稳定性和响应能力，限流确保合法用户不会遇到一个经常被限流或速度缓慢的服务。

本质上，限流是弹性 API 战略的基本组成部分，它将你的 API 从一个易受攻击的开放门户转变为一个受控、安全且高性能的网关。

限流算法：它们如何工作

限流器的有效性取决于其用于跟踪和执行限制的算法。有几种常见的限流算法，每种都有其自身的优点、缺点和适用于不同用例的场景。理解每种算法中限流的步骤是选择正确算法的关键。

1. 固定窗口计数器

这是最简单的算法。它将时间划分为固定的窗口（例如 60 秒）。对于每个窗口，它为每个客户端维护一个计数器。当请求到达时，计数器递增。如果计数器在当前窗口内超过预定义的限制，则后续请求将被阻止，直到下一个窗口开始。

优点： 易于实现和理解。 缺点： 可能导致新窗口开始时出现“突发”流量。如果限制是每分钟 100 个请求，客户端可以在一个窗口的最后一秒发出 100 个请求，并在下一个窗口的第一秒再发出 100 个请求，从而在两秒内有效地发出 200 个请求。

1graph TD
2    A[请求到达] --> B{"当前时间在窗口内？"}
3    B -- 是 --> C{"计数器 < 限制？"}
4    C -- 是 --> D[处理请求]
5    D --> E[递增计数器]
6    C -- 否 --> F["阻止请求 (429)"]
7    B -- 否 --> G[新窗口]
8    G --> H[重置计数器]
9    H --> C

2. 滚动窗口日志（或滑动窗口日志）

此算法保留客户端发出的每个请求的时间戳日志。当新请求到达时，系统通过查看日志中的时间戳来计算在过去 N 秒（窗口大小）内发出了多少个请求。如果计数超过限制，则阻止该请求。窗口外较旧的时间戳将被丢弃。

优点： 更准确，避免了固定窗口的“突发”问题。 缺点： 需要为每个客户端存储可能大量的时间戳，这可能占用大量内存，特别是对于高流量的 API。

3. 漏桶

想象一个具有固定容量且底部有一个小孔的桶。请求就像水滴，进入桶中。如果桶已满，新的请求就会溢出并被丢弃。水以恒定速率从孔中漏出，代表处理速率。

优点： 平滑突发流量，确保恒定的输出速率。 缺点： 如果桶已满但未溢出，请求可能会被延迟。它不直接限制请求数量，而是限制其处理速率。

1graph TD
2    A[传入请求] --> B{桶满？}
3    B -- 否 --> C[添加到桶中]
4    B -- 是 --> D["丢弃请求（溢出）"]
5    C --> E[请求以恒定速率漏出]
6    E --> F[处理请求]

4. 令牌桶

这是最灵活、使用最广泛的算法之一。想象一个装有“令牌”的桶。请求消耗令牌。如果请求到达时有可用令牌，则移除一个令牌并处理请求。如果没有可用令牌，则阻止请求。令牌以固定速率添加到桶中，直到达到最大容量。

优点： 允许突发流量（最高可达桶容量），同时仍强制执行长期平均速率。高效，因为它只需要存储当前令牌计数和上次补充时间戳。 缺点： 需要仔细调整桶容量和补充速率。

1graph TD
2    A[令牌以固定速率生成] --> B["令牌桶（最大容量）"]
3    B -- 令牌可用 --> C[请求到达]
4    C --> D{令牌 > 0？}
5    D -- 是 --> E[消耗令牌]
6    E --> F[处理请求]
7    D -- 否 --> G["阻止请求 (429)"]

5. 滑动窗口日志 vs. 滑动窗口计数器（常被混淆）

虽然“滑动窗口日志”涉及存储每个请求的时间戳，但一个更优化的版本，通常被称为滑动窗口和限流（具体来说，是滑动窗口计数器或滑动窗口算法），结合了固定窗口和滚动窗口日志的优点。

它的工作原理是：

• 将时间划分为固定窗口（类似于固定窗口计数器）。
• 为当前窗口保留一个计数器。
• 估算前一个窗口的计数。
• 当请求到达时，它根据请求到达当前窗口的时间点，计算当前窗口计数和前一个窗口计数的加权平均值。

例如，如果你有一个 60 秒的窗口，并且请求在当前窗口开始 30 秒后到达，该算法可能会考虑前一个窗口计数的 50% 和当前窗口计数的 50%。这提供了比固定窗口平滑得多的速率限制，同时比存储所有时间戳更节省内存。

优点： 在准确性（避免突发问题）和内存效率之间提供了良好的平衡。 缺点： 实现比固定窗口稍复杂。

理解每种算法中限流的步骤，可以让你选择最适合你特定性能、内存和准 性要求的算法。

实现限流器：最佳实践

实现一个有效的限流器不仅仅是选择一个算法；它需要仔细考虑放置位置、响应处理和配置。

在哪里实现限流器

你的限流器的位置会显著影响其有效性和性能。

• API 网关/负载均衡器： 这通常是进行初始限流的理想位置。像 Nginx、Kong、AWS API Gateway 或 Google Cloud Endpoints 这样的工具都提供内置的限流功能。

  • 优点： 保护所有下游服务，集中管理，可以在请求到达你的应用服务器之前高效处理高流量。
  • 缺点： 控制粒度较粗（例如，在没有额外上下文的情况下，不易区分经过身份验证的用户操作与通用 API 调用）。

• 应用层（微服务）： 为了更精细的控制，你可以在应用程序代码或单个微服务中实现限流。

  • 优点： 允许制定高度具体的规则（例如，“用户 X 每分钟只能发布 5 条评论”，“每个邮箱每 5 分钟只能尝试 1 次密码重置”）。可以利用应用程序特定的上下文（用户 ID、订阅等级）。
  • 缺点： 需要更多的开发工作，可能增加单个服务的开销，并且可能无法在流量冲击你的应用程序代码之前提供保护。

• 数据库/缓存层（例如 Redis）： 对于分布式系统，像 Redis 这样的共享、快速数据存储通常用于跨应用程序的多个实例存储和同步速率限制计数器。

  • 优点： 在水平扩展的应用程序中实现一致的限流。
  • 缺点： 引入了外部依赖和潜在的延迟。

最佳方法通常涉及分层策略：在网关级别设置粗粒度的限流器进行整体保护，同时在特定的应用服务内部结合更细粒度、上下文感知的限流。

处理速率限制超出响应的策略（HTTP 429）

当客户端超过其允许的请求速率时，限流器应返回 HTTP 429 Too Many Requests 状态码。这是指示用户在给定时间内发送了过多请求的标准方式。

至关重要的是，429 响应应包含特定的头部信息，以指导客户端如何继续：

• Retry-After： （推荐）指示客户端在发出另一个请求之前应等待多长时间（例如，Retry-After: 60 表示 60 秒）。这有助于防止进一步过载，并指导客户端优雅地退避。
• X-RateLimit-Limit： 当前窗口允许的最大请求数。
• X-RateLimit-Remaining： 当前窗口中剩余的请求数。
• X-RateLimit-Reset： 当前速率限制窗口重置的时间（例如，Unix 时间戳或 UTC 日期）。

这些头部对于 API 连接性 至关重要，允许客户端实现智能重试机制，避免反复触发 速率限制超出 错误。

优雅降级与沟通

仅仅阻止请求是不够的。当发生 API 速率限制超出 时，你需要制定系统及用户如何应对的策略。

• 清晰的错误信息： 429 响应体应包含人类可读的消息，解释请求被阻止的原因，并可能指向 API 文档中的限流策略。
• 客户端最佳实践： 鼓励 API 消费者为重试实现指数退避和抖动。这意味着在失败后，他们每次重试前等待的时间稍长一些，并添加一个小的随机延迟（抖动），以防止所有客户端在同一时刻重试。
• 优先级（高级）： 对于关键内部服务，你可能会实施不同的限流层级，甚至允许某些高优先级请求在高峰时段绕过限制，尽管这会增加复杂性。

配置最佳速率限制的技巧

设置正确的速率限制是一种平衡行为。太严格，会挫伤合法用户；太宽松，则存 滥用风险。

• 了解你 API 的使用模式： 分析历史数据。典型流量是多少？高峰时段是什么时候？单个客户端的“正常”行为是什么？
• 考虑资源限制： 你的服务器、数据库和第三方服务在性能下降前实际能承受多少负载？
• 按端点区分： 并非所有端点都同等重要。登录端点可能需要比公共数据检索端点更严格的限制。
• 分层限制： 根据用户身份验证、订阅计划或 API 密钥类型提供不同的速率限制。例如，匿名用户获得 10 次/分钟，免费用户获得 100 次/分钟，付费客户获得 10,000 次/分钟。
• 从保守开始并调整： 通常更安全的是从稍严格一些的限制开始，然后根据用户反馈和监控数据放宽限制，而不是一开始就太宽松并遭受服务中断。
• 监控和告警： 持续监控限流统计数据（被阻止的请求、429 响应）。为异常模式或持续的高阻止率设置告警，这可能表明存在攻击或需要调整限制。
• 记录你的策略： 在你的 API 文档中清晰地发布你的限流策略。这为开发者设定了期望，并帮助他们设计应用程序以优雅地与你的 API 交互。

通过遵循这些最佳实践，你可以构建一个健壮的限流器，有效保护你的 API，同时不会过度阻碍合法使用，确保你的服务永远不会意外地因限流而变得无响应。

常见挑战与解决方案

虽然必不可少，但实施限流并非没有复杂性，尤其是在分布式环境中。

分布式系统与同步挑战

在微服务架构或水平扩展的应用程序中，单个客户端的请求可能会命中 API 的不同实例。如果每个实例维护自己的本地计数器，则很容易绕过整体的速率限制。

• 解决方案：集中式计数器存储： 使用像 Redis 这样的共享、高性能数据存储或分布式缓存来维护和同步所有实例间的速率限制计数器。每个实例在 Redis 中递增计数器，确保对客户端请求速率有一致的视图。这正是 滑动窗口和限流 算法经常表现出色的地方，因为 Redis 可以高效管理必要的数据而不会占用过多内存。
• 解决方案：API 网关： 如前所述，集中式 API 网关可以在请求到达单个服务实例之前强制执行速率限制，从而简化了下游服务的问题。

误报与管理合法流量高峰

有时，请求的突然激增可能是合法的（例如，热门新闻事件驱动流量、新功能发布）。激进的限流可能会无意中阻止真实用户。

• 解决方案：突发容量（令牌桶）： 令牌桶算法非常适合这一点。它允许请求的临时突发（最高可达桶容量），即使平均速率较低。这适应了合法的、短期的流量高峰，而不会立即触发 速率限制超出 错误。
• 解决方案：动态调整： 实施一个可以根据整体系统健康状况或已知事件动态调整速率限制的系统。这很复杂，但可能非常有效。
• 解决方案：用户细分： 根据用户类型区分速率限制（例如，高级用户获得更高的限制）。这确保关键用户在流量高峰期间受影响的可能性较小。

处理用户无意中被限流的场景

合法用户可能由于客户端代码错误、配置错误的脚本，甚至是突然的、合法的更多数据需求而触发速率限制。

• 解决方案：清晰沟通（429 头部和错误信息）： 如前所述，提供明确的 Retry-After 头部和信息丰富的错误消息。这有助于客户端理解情况并进行调整。
• 解决方案：API 密钥管理与监控： 为用户提供单独的 API 密钥。这允许你跟踪每个密钥的使用情况，识别滥用模式，并直接与相关方沟通。如果检测到滥用，它还允许你暂时阻止单个密钥而不影响他人。
• 解决方案：开发者门户： 提供一个开发者门户，用户可以监控自己的 API 使用情况，查看其速率限制状态，并在其用例需要时请求更高的限制。这种透明度建立了信任并减少了挫败感。
• 解决方案：渐进式退避： 考虑暂时减慢响应速度或为接近其限制的客户端返回更简单的数据集，而不是立即阻止。这可以是在硬阻止之前的一种优雅降级形式。

通过预见这些挑战并应用适当的解决方案，你可以构建一个更具弹性且用户友好的限流系统，确保你的 API 永远不会因合法使用而被无意中限流。

结论：健壮 API 设计的必备要素

在日益互联的数字世界中，API 是创新的命脉，实现了无数应用程序之间的无缝通信和数据交换。然而，这种力量伴随着保护这些关键接口免受滥用、过载和恶意攻击的责任。这正是限流所实现的目标。

我们已经探讨了限流作为一种保护机制的基本意义，它保护你的基础设施，确保资源公平分配，并防止代价高昂的服务中断。我们深入研究了限流器是什么，以及各种限流算法——从简单的固定窗口到更复杂的滑动窗口和限流——各自提供了管理流量流的独特方式。

从 API 网关的战略性部署到微服务内部的精细控制，从通过 HTTP 429