速率限制是如何工作的？

Scrapeless Web Unlocker 会为采集工作流获取网页内容，而这些应用仍需遵守源站访问策略并管理自身的工作负载。

速率限制是如何工作的？

速率限制会在一段时间内根据额度评估活动，并决定请求是否可以继续。策略定义了被计数的活动、其所属的身份或范围、允许的速率或突发量，以及在额度耗尽时采取的动作。该机制可以保护服务、公平分配容量，或执行用量协议。

请求额度与授权并不相同。调用方可能拥有有效凭证却超出额度，或在低于速率阈值的情况下仍然无权访问某个资源。诊断这两种情况需要结合真实的响应和服务策略，而不能仅凭流量规模做出假设。

速率限制策略到底在数什么？

速率限制策略会在定义好的范围内统计定义好的工作单元。工作单元可以是请求、字节数、操作次数，或加权成本。范围可以是账号、凭证、端点、租户或网络身份。多个范围可以同时生效，例如租户额度与单独的高成本操作额度。

计数所用的身份会影响公平性。一个网络地址可能代表许多位于共享基础设施之后、彼此无关的用户。一个账号可以使用多组凭证。如果预期的策略是账号级的，那么创建另一组凭证并不会产生新的合法额度，除非服务明确说明会这样做。

加权限制可以更好地体现高成本操作，但其成本规则必须可理解。一次覆盖大型集合的搜索会比读取缓存记录消耗更多容量。客户端无法仅凭响应大小或延迟推断这些权重。

要将持续速率、突发允许和长期配额区分开来。服务可能允许短暂突发，同时维持较低的平均速率。按月的使用权利是另一类边界。满足短期速率并不代表仍然具备可用的长期容量。

固定窗口和滑动窗口是如何工作的？

固定窗口限制器会在离散区间内统计活动，而滑动窗口限制器会评估一个移动中的时间区间。固定窗口易于描述，但接近区间边界的流量可能在相邻窗口中聚集。该突发是否可接受取决于被保护的系统。

滑动日志可以保留相关请求的时间戳，并统计仍处于移动区间内的那些请求。滑动计数器可以通过邻近计数器近似表示一个移动区间。这两种方法在状态成本和精度上各不相同，因此仅说“滑动窗口”并不能完整描述算法。

该 速率限制器算法比较 介绍了固定窗口、滑动方法、令牌桶和漏桶。选择应依据所需的突发行为和实现约束，而不是声称某一种方法永远最佳。

定义时间源与更新语义。在分布式服务中，分散的工作进程如果评估的是陈旧计数器，可能会放行超出预期的工作量。检查与状态更新需要达到策略所需的原子性。一个在单进程中正确的算法并不会自动提供全局正确的额度。

令牌桶和漏桶有何不同？

令牌桶会在额度上限之内补充令牌，并在接纳工作时消耗该额度。未用完的额度可以支撑后续的突发，但会受到桶容量限制。补充值控制了随时间推移的持续接纳速率。

The 令牌桶和漏桶流量模型 解释速率、突发大小和时间之间的关系。要将这些概念应用到 API 请求中，就需要定义一个令牌代表什么。它可以代表一次请求，或代表其他形式的成本单位。

漏桶术语可以用来描述监管或整形。在整形设计中，排队的任务会以受控的速率被释放。队列需要一个最大容量、一个过期策略，以及对无法接纳的任务的处理决策。一个无界队列只会把过载转化为不断增长的内存占用和延迟。

不要假设突发配额是每个端点都可以单独使用的额外容量。多个客户端可能会同时消耗其配额。容量规划必须考虑到该策略所允许的合并行为。

HTTP 429 向客户端传达了什么信息？

HTTP 429 表示服务器认为客户端在相关时间段内发送了过多的请求。 429 状态码定义 将计数机制和客户端标识策略留给服务器处理。仅凭状态本身无法判断该配额是属于凭证、用户、端点还是其他范围。

检查已记录的响应字段和提供方仪表板，以确定实际的策略。不要假设每个服务都使用相同的请求头名称或单位。剩余额度数值可能指的是某一项策略，而同时还适用另一项更为严格的策略。

HTTP 403 描述的是被拒绝的操作，而不是专门用于标识速率耗尽。HTTP 503 关乎服务可用性，并且可能由多种原因导致。 HTTP 响应语义 提供更广泛的区分。以成功状态返回的 HTML 访问页面，在采集器将其作为数据接受之前，也需要对其内容进行检查。

当工作负载超出已记录的许可范围时，应暂停接收受影响的工作，直到应用程序的运行策略允许为止。保留未完成任务的状态，并报告受限制的范围。容量或权限的变更应通过提供商支持的流程进行。

速率与并发性有何不同？

速率衡量的是一段时间内的活动量；并发量衡量的是同时处于活动状态的操作数量。即使客户端的工作线程池很小，如果每个操作完成得很快，仍然可以产生很高的请求速率。当操作持续活跃时间较长时，即使请求速率较低，也可能占用大量的并发容量。

在两者都重要时使用单独的控制。调度器可以管理接收速率，而工作池限制正在进行的工作量。按来源的控制可防止大型全局队列压垮某一个目标。账户级别的控制在原本独立的任务之间保持总体配额。

分页说明了这种区别。顺序游标遍历在大型导出过程中可能只使用一个活跃请求，却消耗许多请求次数。即使浏览器会话发送的集合请求很少，在等待页面交互时依然可以保持活跃。建模时应关注提供方实际限制的资源。

为在队列中等待的工作定义取消机制和截止时间。一个较早的收集请求在超过其新鲜度截止时间后，可能不再有用。丢弃过期的工作并记录原因，比在看似当前的完成时间戳下晚些交付要更为诚实。

Scrapeless 在工作负载控制中处于什么位置？

Scrapeless 提供采集功能，而由你的应用程序来决定其允许的工作负载和接收策略。 Web Unlocker 不会因此获得超出来源访问规则的权限。请将采集凭据、来源权限和调度策略区分开来。

请提供需要翻译的英文内容。 Scrapeless API 密钥要求 描述身份验证。一个可用的密钥既不意味着无限并发，也不意味着可以访问所有产品。请使用适用于所选服务的控制项和账户权限。

减少不必要的工作可以同时改善产能利用率和数据新鲜度。 增量收集和记录变更检测 将未更改的内容与已更改的业务记录分离开来。仅在源行为支持的情况下应用这些机制。

监控已接受的工作、被拒绝的工作、队列等待时间、已接受的记录以及所涉及的策略范围。仅仅依靠收集请求次数无法解释一次受限运行是否产出了有用的数据集。 Scrapeless 定价 用于成本规划，同时与源端的独立访问和容量规则相配合。

结论

一个清晰的限流设计会明确被计数的工作内容、身份标识、时间模型以及过载决策。将准入控制和并发控制与这些边界相匹配，然后显式记录未完成的工作，这样流量控制就不会在无声无息中演变成数据缺失。