如何设置网页抓取并发以避免重试风暴

简要说明

• 并发限制控制进行中的工作；速率限制控制新请求的启动速度。
• 将限制应用于实际共享容量的源和账户范围，而不仅仅是每个工作进程独立应用。
• 重试的请求必须消耗与首次尝试相同的准入预算。
• 将HTTP 429视为共享冷却信号，并保留任何有效的Retry-After指令。
• 仅在接受的数据吞吐量在不产生不可接受的延迟、错误或队列增长的情况下提升并发性。
• 将CAPTCHA任务和目标请求放在独立的池中，并在它们之间进行显式交接。

抓取器可能发起更多请求但收集到更少可用数据。慢速响应会占用连接，工作进程重复失败请求，队列中充满正在进行的工作副本。增加工作进程数量可能会放大相同的瓶颈。有用性能指标是任务截止时间内交付的接受数据，而不是启动的请求数量。

本指南解释了如何为授权的采集工作流设置抓取并发限制。它涵盖了源级准入、重试调度、浏览器容量和受控调优过程。CapSolver 在需要时融入独立支持的CAPTCHA任务阶段。无论工作进程池更大还是挑战完成，源的速率策略都不会改变，因此调度器必须在整个运行过程中保持控制。

将并发与请求速率分开

并发是当前进行中的操作数量，而请求速率是随时间变化的启动次数。仅靠并发限制无法保证稳定的请求速率，因为响应时间会影响槽位释放的速度。

想象一个允许的测试源有四个活动请求槽位。如果请求快速完成，这些槽位可以在短时间内生成许多启动。如果响应变慢，相同的四个槽位在占用更长时间的同时生成更少的启动。两种行为都遵守并发限制。当启动必须保持在基于时间的配额内时，需要单独的速率控制器。

并发术语表 和 速率限制术语表 描述了相关概念。在调度器中，将它们记录为单独的设置。添加最大等待队列和任务截止时间，以防止延迟工作在合理限制后无限积累。

没有普遍最佳的并发请求数量。源策略、负载大小、浏览器渲染、带宽和下游处理都会影响有效的运行点。从源的文档允许和您自己的容量开始，然后测量明确允许的工作负载。

第1步：定义共享限制的作用域

并发限制必须覆盖竞争相同容量或权限的工作者。当多个进程、机器或任务访问同一受限源时，每进程设置是不够的。

在创建工作者之前确定相关作用域。它可能是主机名、API凭据、源定义的账户配额，或受控的浏览器会话。使用提供者描述的作用域，而不是假设每个URL都有独立容量。子域名也可能共享基础设施或账户级配额。

将全局容量与源容量分开。全局上限保护您自己的机器和出站资源。每个源的上限防止一个快速队列消耗所有可用槽位。如果源暂时暂停，另一个独立允许的源可以继续运行，而无需借用暂停源的身份或配额。

对于浏览器工作流，决定什么占用一个槽位：导航、活动页面或整个会话。绑定到账户的会话不应在并发任务之间随意共享。其cookie、待处理操作和预期目标需要在任务持续期间有所有者。

第2步：让每个请求通过准入检查

准入应在请求开始前发生，并应适用于初始尝试、由客户端控制的重定向以及工作进程重启。直接发送到传输的重试路径可能破坏主调度器的限制。

为预期观察使用一个任务身份，并为传输工作使用单独的尝试身份。这允许队列区分合法重试和重复的计划任务。如果工作进程重启，它应在创建另一个请求前检查观察是否已完成。

当相关操作实际完成或传输被取消时，应释放槽位。仅因调用者停止等待而释放容量可能导致隐藏请求超出名义限制。在状态未解决前，将不确定或仍在运行的工作视为占用容量。

同时限制队列。当工作过多时，延迟后续收集窗口、拒绝超额需求或根据服务协议减少请求范围。保持无限积压会将失败转移到内存压力和过时观察。

第3步：通过受控队列安排重试，而非到处休眠

重试应返回到带有未来可执行时间、尝试次数和剩余任务截止时间的受控队列。工作进程内部的分散休眠调用会使协调共享源冷却变得困难。

< a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/429" rel="nofollow">HTTP 429 状态码 表示在相关时间段内发送了太多请求。当响应包含 Retry-After 时，保留其延迟或日期语义。不要让每个工作进程独立选择更短的等待时间。

为受影响的作用域使用共享冷却。在冷却激活期间，包括从未失败的请求，停止接纳新工作。已运行的工作可能完成，但一个工作进程的成功响应不应自动清除另一个工作进程观察到的有效冷却。

对于没有明确服务器指导的临时读取失败，应用适合操作的有限重试策略。交错计划可以避免暂停后的同步爆发。除非操作效果和可重复性已知，否则不要为表单提交或其他状态更改操作添加重试。

观察结果	调度器响应	需保留的证据
HTTP 429	暂停受影响的作用域并尊重重试指导	源作用域、响应时间、冷却期
临时读取超时	仅在尝试和截止时间预算内重新排队	尝试身份和剩余时间
身份验证或访问拒绝	停止或路由以进行访问审查	被删除的响应类别
支持的CAPTCHA检查点	进入独立允许的挑战阶段	当前观察和挑战上下文
无效提取的记录	调查解析或源数据	保留的页面引用和验证错误

领取您的CapSolver优惠代码

立即提升您的自动化预算！
在充值CapSolver账户时使用优惠代码 CAP26，每次充值可获得额外 5% 的奖励 —— 无限制。
现在在您的 CapSolver仪表板 中领取

第4步：防止挑战处理增加需求

CAPTCHA检查点应创建受控交接，而不是与抓取器并行的额外请求循环。即使需要支持的挑战步骤，目标观察仍是一个任务。

CapSolver createTask 文档 定义了任务提交，getTaskResult 文档记录了结果检索。遵循适用的任务要求，并将返回的任务身份与当前观察相关联。轮询已知任务和创建新任务是不同的操作。

为该阶段分配单独的活动工作、时间和尝试限制。当浏览器恢复时，目标的速率配额仍然适用。挑战结果不应授予源冷却的即时例外，也不应导致所有暂停的工作进程同时重启。

如果任务提交在确认前超时，保留不确定性。盲目提交另一个任务可能导致重复工作。调度器应知道它是在等待现有结果、调查不确定请求，还是为审查关闭观察。

目标继续后，验证预期页面并记录合同。否则，增加的挑战吞吐量可能掩盖接受收集输出未改善的事实。

第5步：进行受控的并发增加

并发增加应仅更改一个容量设置，同时保持比较工作负载和接受标准稳定。使用自有测试源或另一个明确允许负载测试的环境。

建立基线

从一个小的允许工作负载开始，记录完成的观察、接受的记录、请求延迟、错误类别和队列年龄。将等待准入的时间与网络或浏览器上的时间分开。长时间的端到端持续时间可能有不同原因，需要不同修复。

在同一份报告中保持首次尝试和重试可见。如果接受的记录保持不变而总请求数增加，额外流量并未产生有用吞吐量。在增加工作进程前，检查重试策略、页面准备就绪或下游验证是否解释了差异。

仅在结果改善时增加

按适度的预定义步骤提高限制并观察相应间隔。当接受吞吐量趋于平缓、失败频率上升或尾部延迟超过任务需求时停止增加。这些观察结果确定了该工作负载的容量边界；它们不证明整个供应商的永久限制。

在不同负载大小和页面类型上重复代表性案例。轻量级HTML页面和JavaScript密集型仪表板可能需要非常不同的浏览器资源。避免仅从最简单的页面选择操作限制。

保留变化空间

选择低于失败边界的操作点，而不是永久运行在短暂通过的最高值。源性能和您自己的基础设施可能变化。保留容量用于计划工作，并防止探索性任务占用整个池。

理解自动节流控制

自动节流可以适应观察到的延迟调整请求时间，但其行为取决于实现和配置的限制。在将其与第二个调度器结合使用前，请阅读消费框架的文档。

< a href="https://docs.scrapy.org/en/latest/topics/autothrottle.html" rel="nofollow">Scrapy AutoThrottle 文档 描述了目标并发和基于延迟的调整，同时尊重配置的并发上限。其目标不是无条件承诺始终有确切数量的请求处于活动状态。非成功响应在延迟计算中也受到特殊处理。

使用框架特定的控制在其文档范围内。爬虫的本地节流不会自动协调独立部署或施加总组织配额。如果多个任务共享一个配额，请在这些独立工作者上方放置共享控制器。

记录每次运行使用的有效配置。如果框架、传输池、重试中间件和外部调度器同时变化，那么并发实验将难以复现。浏览器基础设施概述 为分离这些资源提供了有用背景。

在增加容量前诊断吞吐量下降

较低的接受吞吐量可能来自网络、源、浏览器、解析器或目标存储。更多抓取工作进程仅帮助部分瓶颈，可能使其他瓶颈更糟。

如果队列增长而网络槽位保持空闲，请检查准入和冷却逻辑。如果浏览器内存上升，请审查会话生命周期和页面清理。如果请求完成但记录被拒绝，请检查内容准备就绪、模式变化和解析器行为。如果接受的记录等待存储，请从下游写入器施加背压。

保持明确的暂停程序。操作员应能停止一个源的新启动，保留进行中的任务身份，并在问题理解后逐步恢复。同时重启所有工作进程是受控容量重新开放的糟糕替代方案。

为有用的数据收集进行调优

围绕源策略、实际资源拥有和接受记录设置抓取并发。让每次尝试通过准入，协调冷却，并仅在完整流水线受益时增加负载。

对于需要支持的CAPTCHA处理的工作流，请在独立的受限阶段使用 CapSolver，然后返回到相同源控制。有纪律的调度器使系统在负载和页面行为变化时更容易操作。

常见问题

Q: 并发限制与每秒请求数限制是否相同？

A: 不是。并发限制控制活动操作。请求速率限制控制随时间的启动次数，因此您可能需要两者。

Q: 每个工作进程应独立处理HTTP 429吗？

A: 共享相同速率限制作用域的工作进程应协调其冷却。独立重试可能在每个工作进程看似保守时重新创建突发流量。

Q: 我可以通过增加并发来解决缓慢的抓取吗？

A: 仅当额外容量在源允许限制内改善接受输出时才有效。首先确定瓶颈是采集、渲染、解析还是存储。

Q: CAPTCHA结果是否允许请求跳过调度器？

A: 不。挑战处理完成后，目标的速率和并发规则仍然适用。

Q: 下游存储落后时该怎么办？

A: 通过背压减少或暂停新采集。无限的已获取页面队列会增加资源使用，并可能在接受前使观察过时。