什么是速率限制器？
Scrapeless Web Unlocker 检索公共网页内容以支持数据工作流程，这些工作流程的调用者仍应强制执行明确的请求速率、公平性和下游容量。
TL;DR
- 速率限制器控制着随时间的操作。 它通过决定工作何时可以进行来保护能力、公平、成本和服务目标。
- 密钥确定共享边界。 依据帐户、凭据、路线、主机、租户、区域或其他定义的主题，可能会有使用限制。
- 算法塑造突发行为。 固定窗口、滑动窗口、令牌桶和漏桶有不同的权衡。
- 并发和速率是不同的。 一个系统可以有几个活动请求，但仍然超过每分钟的允许值，或者反之亦然。
- 客户需要可观察的决策。 限值响应应识别政策边界，并在协议支持时传达何时容量可用。
速率限制器定义
速率限制器是一种控制工具，根据时间测量的策略允许、延迟或拒绝操作。操作可能是HTTP请求、消息、登录尝试、作业提交、昂贵的查询或对计量依赖的调用。该策略将数量与身份和时间模型挂钩。
限流器位于入站路径上。它读取一个密钥，检查状态，原子性地更新该状态，并返回一个决策。结果在不受控的需求到达组件之前保护了稀缺资源或公平规则，否则将导致组件失败或变得太昂贵。这里使用的主要术语如下 RFC 6585 对 HTTP 429 的定义，这为这个概念提供了一个具体的技术边界，而不是将其视为一个营销标签。
有用的定义还说明了这个概念不做什么。速率限制器与并发信号量、队列容量、计费配额或网络拥塞控制不同。这些机制可能会协同工作，但每个机制测量的条件不同，并产生不同的响应。保持这一边界可见，防止架构图将保证分配给属于另一个层的组件。
速率限制决策是如何做出的
每个决策结合了一个主题、一个规则、存储的状态和一个动作。分布式限流器还需要一致性规则，以确保多个网关不会各自独立地消耗全部配额。
- 从已验证的帐户、路由、主机、租户或其他批准的边界中派生限制关键。
- 加载所选算法所需的计数器、时间戳、桶余额或排队出发时间。
- 请原子地应用该政策，以便同时请求不会重复使用相同的容量。
- 允许、延迟或拒绝操作，并公开足够的元数据以便进行可观测性和客户端行为分析。
- 使过期或紧凑限制器状态，以便不活动的键不会导致无限制的存储增长。
一个固定窗口在离散间隔内计数，简单但允许边界突发。滑动窗口通过更多状态或近似来平滑该边缘。令牌桶在上限内累积权限，允许控制的突发。漏桶使离开形状朝着更稳定的流动。此行为在 MDN 速率限制术语表该源是有用的，因为它描述了实际的执行或数据模型，而不是依赖于一个松散的类比。
速率限制算法比较
| 算法 | 突发行为 | 典型权衡 |
|---|---|---|
| 固定窗口 | 大边缘突发是可能的 | 简单的状态但粗糙的公平性 |
| 滑动日志 | 在滚动区间内精确 | 更多内存和清理工作 |
| 滑动计数器 | 更平滑的近似滚动速率 | 在边界附近的近似 |
| 令牌桶 | 允许突发直到桶的容量 | 需要重新填充和原子花费逻辑 |
| 漏桶 | 形状输出趋向稳定的节奏 | 增加排队延迟或削减溢出 |
算法选择遵循产品行为。交互式客户端可能需要适度的突发，然后是稳定的平均值。批处理系统可能更喜欢按节奏离开。注重安全的端点可能使用更严格的每个身份规则，以及单独的全局保护。
速率限制器保护系统的地方
公共API
限制在账户之间保持公平访问，防止一个调用者消耗共享的请求能力。
身份验证
更严格的政策可以减缓重复尝试，同时保持正常账户访问和审计信号。
后台作业
入场控制防止生产者淹没工人队列和昂贵的下游服务。
成本边界
计量模型或第三方依赖项可以通过与租户和操作类型对齐的预算进行保护。
这些用例共享选择规则：选择一个速率限制器，因为它的执行和拥有模型与工作负载匹配，而不是因为名称听起来更高级。单一的全局限制很少足够适用于多租户服务。分层规则可以保护整个系统、一个租户和一条昂贵的路线，而不让每个请求有相同的成本假设。
密钥、配额和公平性
有用的政策说明谁共享能力，什么操作消耗它，能力返回的速度，是否允许突发，以及在达到限制时调用者观察到的内容。
- 选择一个值得信赖的密钥。 未经身份验证的地址可能将不相关的用户归为一组，或者在会话期间发生变化，而账户密钥则更直接地映射到所有权。
- 按成本为操作定价。 一个重的导出和一个元数据查找可能需要不同的权重，而不是一个请求等于一个单位。
- 分层全局和本地规则。 在保护服务的同时，保持每个租户的公平性和特定路由的容量。
- 保持决策原子。 分布式网关需要共享或分区状态，不能超出相同的限额。
- 公开政策结果。 指标和协议响应应区分速率耗尽与身份验证、验证和服务器故障。
HTTP 429 状态表明请求速率条件，但服务器仍然选择如何识别调用者和计算请求。客户端应将响应视为政策信号，而服务所有者应记录稳定的限制范围，避免泄露敏感的强制执行细节。相关的主要参考是 NGINX 请求限制指导，它澄清了选择背后的存储、执行或互操作性假设。
速率限制器设计错误
在平均负载下，限制器可能看起来正确，但仍会在边界、时钟倾斜或许多网关更新同一状态时出现故障。公平性错误通常隐藏在密钥选择内部，而不是计数器算法中。
- 将速率与并发混淆。 每秒的政策和最大活动政策保护不同的维度，应该分别测量。
- 信任客户端时钟。 服务器端决策应使用受控时间源，并定义时钟移动期间的行为。
- 使用不稳定的密钥。 变化或容易被乘的身份使得公平性不一致，状态难以解释。
- 忘记突发语义。 两个具有相同平均速率的政策可能会产生非常不同的下游峰值。
- 意外地失败开放。 存储故障需要每个路由的明确可用性与保护决策。
故障应追溯到最小的责任层。 当调用者报告意外拒绝时，在更改通告的速率之前，检查派生的密钥、应用的规则、存储的余额、决策时间和区域状态。这一做法产生有用的纠正措施，而不是模糊的指令来增加更多的容量。
Web 数据收集中的速率控制
即使获取提供者可以接受许多同时调用，Web 收集也需要速率控制。目标主机、账户预算、解析器、存储层和消费者各自具有独立的能力，这些能力应影响入场。
对于公共网络输入，获取层应记录请求的 URL、最终 URL、收集时间、响应模式，以及在下游处理开始之前的内容检查。将限制密钥和政策名称附加到内部作业元数据，而不公开凭证或敏感的强制执行状态。这个移交为分析师提供了一个可重现的源记录，并保持收集行为与解释分开。
Scrapeless 处理开头一句中描述的托管网络收集步骤。应用程序仍然拥有源批准、字段定义、工作负载界限、保留、访问控制和验证。Scrapeless 拥有请求的检索操作，而调用者拥有源授权、每主机的节奏、公平性、预算和下游负载。这些层之间的清晰合同使后续变更更易于测试。
当用例需要审核时，管道应保留原始证据和策划输出。原材料支持在解析器或模式更改后进行重新处理；策划表支持稳定分析。队列不应成为逃避速率政策的方式；根据新鲜度安排工作，并在收集前删除不再有用的作业。这两种表示回答不同的操作问题，不应被误认为是重复的。
速率限制器审查清单
在设计审查期间使用以下问题。书面的答案比假设的默认值更有价值，因为它揭示了团队对速率限制器的分歧。
- 限制键代表哪个身份或资源？
- 每个操作消耗什么单位？
- 该策略是平均速率、突发允许、并发上限，还是它们的组合？
- 限制器状态存储和原子更新的位置在哪里？
- 区域网关如何共享或划分配额？
- 当没有可用容量时，调用者观察到什么？
- 如何在不失去活动状态的情况下使陈旧的键过期？
- 哪些仪表板同时显示公平性和受保护资源的健康状况？
当其身份、时间模型、原子性、过载行为和可观察性与受保护资源和面向用户的合同匹配时，速率限制器就是准备好的。随着工作负载形状、数据量、服务限制或消费者期望的变化，请重新审视答案。对探索性批处理合理的架构可能不适合连续生产路径。
结论
速率限制器将容量或公平性目标转化为随着时间推移的入场决定。它的有效性取决于关键选择、算法、突发政策、分布式状态和明确的客户端响应。强大的系统将速率控制与并发上限、有限队列、成本预算和监控结合起来。限制器应保护有用的服务行为，而不仅仅是产生被拒绝请求的计数。
准备构建一个速率感知的集合管道吗？
将受管理的公共网络检索与明确的速度控制、公平队列、证据检查和成本控制相结合。
今天注册并获得 5美元的免费积分 — 无需信用卡.
领取您的5美元积分 →常见问题
速率限制和节流之间有什么区别？
这些术语常常可以互换使用，但节流可能特别意味着延迟或调整工作，而速率限制也可以拒绝它。设计文档应说明实际操作：允许、等待、放弃或拒绝。仅靠命名无法告诉客户端容量如何变得可用。
速率限制和配额之间有什么区别？
速率限制控制操作在时间模型上发生的速度。配额通常限制在计费、合同或管理周期内的总使用量。一项请求可以满足短期速率政策，同时仍然超过长期配额，因此生产系统通常会同时执行两者。
HTTP为什么使用状态429？
HTTP状态429表示用户在给定的时间内发送了过多请求。规范将计数和用户识别的方法留给服务器。响应可能包括通知客户端何时适合另一个请求的信息，具体取决于服务合同。
哪种速率限制算法最好？
没有一种算法适用于每个工作负载。固定窗口偏向简单，滑动方法平滑窗口边界，令牌桶允许受控突发，漏桶形成输出。选择所需的精度、突发行为、存储成本、分布模型和合法调用者期望的体验。
高API并发上限是否消除了对速率限制器的需求？
不。并发上限在某一时刻限制活动工作，而速率限制器控制随时间推移的操作。客户端可以保持在并发上限之下，仍然在一分钟内发送过多的短请求。下游服务、目标主机和预算可能也需要比提供者更严格的限制。