批量异步抓取数千个URL

TL;DR

• 批量抓取数千个 URL 是一个队列管理问题，而不是一个 HTTP 问题。
• 使用有限并发、每请求超时、含抖动的重试、检查点和幂等结果键。
• asyncio 和 aiohttp 适合简单的公共页面；浏览器渲染或站点发现应转移到爬虫服务。
• 当批量需要渲染页面、页面伪件或受控的站点级收集而非原始获取时，Nstdata Crawl 是更好的选择。

为什么大批量 URL 会失败

当需要渲染或任务状态时，请从 Nstdata Crawl 开始。

当提交速率、目标站点限制、重试和结果存储被视为一个循环时，批量抓取会失败。一千个 URL 可能会产生重复写入、重试风暴、打开连接，并且在工作者或进程停止后没有可靠的恢复方法。当批量是爬取任务而不是简单的 HTTP 请求列表时，请从 Nstdata Crawl 开始。

第一个设计决策是记录身份。使用标准 URL 加上抓取配置哈希，而不是输入文件中的位置。记录 queued、running、succeeded、failed 和 dead_letter 状态，以及最后的错误和尝试次数。这使得部分运行可以修复。

一个保持有限的异步设计

最安全的模式是一个生产者，一个信号量限制的工作池，和一个持久的结果接收器。aiohttp 文档介绍了异步 HTTP 请求的 ClientSession 模式；官方 aiohttp 指南 是会话生命周期和超时的正确参考。

一种有效的异步模式

以下代码块是对授权公共 HTML 页面的说明。它不会绕过身份验证、验证码或爬虫政策。

import asyncio
import hashlib
import time
import aiohttp

TIMEOUT = aiohttp.ClientTimeout(total=30)

async def fetch(session, sem, url):
    async with sem:
        for attempt in range(4):
            try:
                async with session.get(url, allow_redirects=True) as response:
                    body = await response.text(errors="replace")
                    if response.status >= 500:
                        raise RuntimeError(f"retryable status {response.status}")
                    return {"url": str(response.url), "status": response.status,
                            "sha256": hashlib.sha256(body.encode()).hexdigest(),
                            "body": body, "fetched_at": time.time()}
            except (aiohttp.ClientError, asyncio.TimeoutError, RuntimeError):
                if attempt == 3:
                    return {"url": url, "status": "failed", "attempts": attempt + 1}
                await asyncio.sleep((2 ** attempt) + 0.2 * attempt)

async def run(urls):
    sem = asyncio.Semaphore(25)
    async with aiohttp.ClientSession(timeout=TIMEOUT) as session:
        return await asyncio.gather(*(fetch(session, sem, url) for url in urls))

在生产之前，将内存中的列表替换为数据库或对象存储。不要在一个进程中持有数千个完整的响应体。仅当其状态和内容政策通过时才存储主体，并为其他内容保持一个紧凑的失败记录。

当受控爬取层更好时

当 URL 已知、页面大多由服务器渲染，并且您的团队拥有解析和持久性时，原始异步 HTTP 是合适的。当批量需要 JavaScript 渲染、有限发现、Markdown/HTML/JSON/链接/PDF 伪件、任务状态或可重用提取边界时， Nstdata Crawl 变得更相关。它的 Crawl 定价页面 将 URL 使用与代理使用分开，并区分一次性余额使用与订阅；按接受页面计算成本，而不是按提交 URL 计算。

对于 RAG 工作负载，Crawl for RAG 指南 解释了为什么源元数据和刷新策略应在管道中。对于代理工作负载，MCP web-access 指南 涉及有限的工具访问。爬虫仍然需要您的解析器、模式验证、去重和合法使用政策。 有关相关实施上下文，请参阅 MCP 网络访问指南、RAG 知识库指南、网络爬虫术语表 和 ETL 术语表。

RFC 9309 和 RFC 9110 提供了相关的 HTTP 和爬虫策略上下文。

结论

从一个小的 URL 示例开始，测量接受页面速率和重试速率，然后只有在目标和接收端保持健康时才增加并发性。对于简单的已知 URL 使用异步客户端；在呈现、发现或工件管理成为瓶颈时使用 Nstdata Crawl。下一步是运行一个有限批次，并在安排数千个页面之前检查失败。

常见问题

问：批量爬虫应该使用多少并发请求？

没有通用的数字；开始时要谨慎，遵循目标指导，并仅在观察到响应速度、错误和队列延迟后增加并发性。

问：我如何恢复失败的批次？

针对每个标准 URL 持久化状态，仅重试那些不是最终成功的记录，使用幂等结果键。

问：异步 HTTP 对于重 JavaScript 页面足够吗？

不够。异步 HTTP 下载服务器响应；它不会执行浏览器 JavaScript，这些 JavaScript 创建客户端渲染的内容。

问：我可以批量爬取私有或已登录的 URL 吗？

只有在明确授权和经过批准的凭证处理流程下；此工作流程不涵盖访问控制规避。

问：我应该如何衡量批量成本？

衡量每个接受的、验证的记录的成本，包括重试、代理流量、渲染、存储和下游解析，而不仅仅是请求次数。