如何遵守速率限制：节奏化 API 与网页请求

Scrapeless Web Unlocker 从公共 URL 获取内容，使你的应用可以在单独受控的请求预算内解析响应。

在第一个请求之前就开始遵守限制

遵守速率限制意味着将请求活动保持在服务文档中规定的额度范围内，包括其计数规则和突发约束。一个在触及限制后才开始“礼貌”行为的采集器，已经消耗了超出预期的容量。在网络派发之前构建准入控制：工作先进入队列，调度器检查适用的预算，仅允许获准的工作启动。这种方法使得请求计划在产生流量之前就可以被审查。

阅读服务提供方针对你使用的具体资源的政策。限制可以适用于账户、API key、用户、IP 地址、路由，或这些的组合。搜索和导出端点可能有不同的约束。每日额度可以与更短的滚动时间窗并存。把未文档化的计数器视为未知，而不要假设它也受另一个端点的政策覆盖。

该 HTTP 429 状态定义 标识了请求量限制，但并未标准化每个服务如何识别调用方或如何计数请求。因此，仅靠错误页面无法确立完整的政策。将公开文档和账户配置与任务设置放在一起，并指派一名负责人，在大规模采集开始前解决不清晰的配额问题。

将政策转化为共享预算

共享预算可以防止独立工作进程各自单独消耗同一额度。假设一个虚构账户每分钟允许 60 个新请求，而三个进程各自都认为自己拥有 60 个。每个进程在本地看来都合规，但账户总体上却超出了总额度。解决方案是：对于属于该账户和该政策时间窗的所有工作，使用单一的准入决策。

使用这个假设数字只是为了理解算术，它既不是 Scrapeless 的配额，也不是推荐的运行速率。要为交互式使用、监控调用以及共享该账户的其他应用预留空间。如果这些消费方无法被精确计量，则让采集器的分配保持保守，并记录这一不确定性。将服务提供方的硬性上限与任务被允许消耗的较小额度区分开来。

跟踪服务提供方实际用来抵扣限制的计量单位。有些政策按请求计数；另一些按记录数、处理单元、字节数或操作复杂度计数。一个包含许多操作的批处理仍可能消耗大量容量。为每个队列项记录预算范围和成本模型，以免一个昂贵的导出被当成轻量的元数据查询来准入。

分别控制请求启动和活动工作

请求节奏控制的是新工作启动的频率；并发控制的是同时保持活动的工作量。仅有并发上限无法强制请求速率，因为快速响应会让工作进程在同一时间窗内启动许多操作。仅有启动速率上限在响应变大或变慢时也无法保护内存。应在同一派发器周围同时使用这两种控制。

浏览器任务还需要额外区分。打开一个页面会触发文档、脚本、图片和后台 API 请求。一次导航不一定就是一次源站请求。不要根据浏览器自动化指令的数量来声称自己合规。对于公共数据流程，要理解哪些操作会触发网络活动，并约束任务实际需要的页面和交互。

同时设置队列容量和工作进程容量。无界的积压会把短暂的流量高峰变成数小时的陈旧工作。为任务设定过期时间和清晰的优先级。超过上报时间窗到达的价格观测值可能已经无用。要有意识地丢弃过期未发送的工作，并记录这一决策，使下游消费者能够区分“新鲜度限制”和“记录缺失”。

在增加容量前先减少需求

减少不必要的请求可以为任务真正需要的信息保留容量。谨慎规范化目标 URL，删除重复任务，并仅在资源政策允许的情况下缓存可复用结果。不同的查询字符串可能代表不同内容，因此规范化必须保留有意义的过滤器和页面状态。将不同资源去重合并可以节省调用，但会以牺牲数据质量为代价。

在工作流允许的情况下，使用源支持的通知而不是反复检查。 GitHub REST 使用实践 说明了条件请求和事件投递如何减少不必要的轮询。那些是某个提供方合同的示例，而不是对配额核算的通用豁免。确认你选择的服务如何计数条件响应和通知跟进调用。

将分页控制在同一配额内

分页属于请求预算的一部分，包括那些没有返回任何有用新记录的页面。在启动前预估必要的遍历范围，并在文档中标记的结束位置停止。由于终止规则错误而反复请求最后一页，会消耗容量却不会提升覆盖率。将续传状态与查询一起存储，这样下一步才能沿用相同的结果集定义。

页面大小会改变操作次数和响应成本之间的权衡。更大的页面可以减少往返次数，但会增加内存占用、处理时间和服务工作负载。选择适合任务的、受支持的页面大小，而不是将提供方的最大值当作默认值。一个有代表性的小集合就能揭示解析或存储是否会成为限制环节。

只有在页面中的记录已提交到目标位置后再进行检查点。若在存储完成前推进续传状态，数据集中可能出现无声缺口。一个有用的检查点应包括查询指纹、已接受记录数、完成标记和捕获时间。不要在检查点文件中保存凭据，并在提供方将不透明的续传值视为敏感信息时对其进行脱敏。

让配额限制响应对作业所有者可见

配额限制响应应当在受影响范围内停止新的派发，并让作业保持在清晰的状态。保留状态、已净化的响应细节和策略标识符，以供诊断。不要在服务器实际拒绝请求时，把空结果标记为成功收集。使用者需要知道是不存在任何记录，还是作业并未获取到它们。

将授权、配额、校验和可用性失败区分开来。禁止响应可能代表一次权限决策。格式错误的请求会消耗工作量却永远无法变为有效。相同的 HTTP 状态码可能携带提供方特定的错误细节，因此在对事件分类之前，请阅读文档中说明的响应体。对未解决的作业保留必要证据，以便其所有者做出调度决策。

运行报告应包括已接纳的工作、已完成的工作、被延后的未发送工作以及被拒绝的工作。将这些与已存储记录和来源的完成信号进行比对。只显示成功调用的仪表板，会隐藏那些从未产生数据的需求。保持按账号和端点范围分组的观测结果；把一切聚合成一个百分比，可能会掩盖真正限制本次运行的具体预算。

在 Scrapeless 周围应用这些控制

你的调度器仍然对使用 Scrapeless Web Unlocker进行的采集的授权范围与速度负责。该产品负责获取内容；你的应用程序决定需要哪些 URL、什么算作可接受输出，以及作业是否应继续。将提供方账户的使用约束与目标站点的访问规则以及你自己的报告截止时间区分开来。

使用 Web Unlocker request capabilities 来选择任务所需的响应处理方式，然后查看 Scrapeless pricing 以了解适用的计费模式。本文并未为产品分配配额，也不保证托管访问会移除速率限制。服务套餐与目标的权限边界回答的是不同问题，两者都应体现在采集设计中。

一个可审查的采集方案

一个可审查的方案在流量开始前，就描述好数据集、允许的来源、时间窗口和停止规则。包括预期的分页遍历、共享账号的使用者、缓存新鲜度、队列过期时间以及记录级别的接受标准。让方案足够具体，以便另一位工程师无需阅读采集器实现，也能判断结果是否完整。

例如，一个假想的目录稽核可以限定在一个经批准的类别和一个指定的报告期内。其完成规则是文档说明的最终页面，加上对每条已接受记录完成存储。其停止条件包括额度耗尽、权限失败和任务相关性过期。当作业无法完成时，这种设计可以产生一份有用的部分报告，而不是一个看似成功但覆盖范围无法解释的文件。

结语

在采集数据前规划请求预算，在工作线程之间共享该预算，并在数据集边界衡量完成度。高效的分页、缓存规则、有界队列和明确的停止状态，使采集更易于操作和说明。当容量不足时，应在进一步调度工作前缩小范围或获取适当的额度。