如何解决Python爬虫高并发瓶颈_使用asyncio配合aiohttp异步库-Python教程-PHP中文网

瓶颈不在asyncio或aiohttp本身，而在连接管理、dns解析、信号量误用和异常处理缺失四点；盲目堆高并发数会导致吞吐量断崖下跌，因未配好连接池引发端口耗尽或文件描述符超限，dns未缓存致单次解析达200ms+，信号量与connector.limit未协同导致tcp/tls阶段卡死，且连接复用需满足session复用、keep-alive支持、force_close=false三条件。

如何解决python爬虫高并发瓶颈_使用asyncio配合aiohttp异步库

直接说结论：瓶颈不在 asyncio 或 aiohttp 本身，而在连接管理、DNS解析、信号量误用和异常处理缺失这四点。盲目堆高并发数反而会让吞吐量断崖下跌。

为什么并发数设为100反而比10还慢？

常见现象是：把 asyncio.Semaphore(100) 一设，请求失败率飙升、大量超时、总耗时不降反升。根本原因是没配好连接池，导致系统级资源打满。

aiohttp.TCPConnector 默认 limit=100，但若你同时开100个协程，每个又试图建新连接，会触发端口耗尽或 OSError: [Errno 24] Too many open files
未设置 ttl_dns_cache，每发一次请求都重查 DNS，httpbin.org 这类域名可能单次解析就耗 200ms+
信号量只控“发起”，不控“连接建立”，真正卡住的是 TCP 握手和 TLS 协商阶段

正确做法是让 semaphore 和 connector.limit 协同：前者控并发请求数（逻辑层），后者控底层连接数（网络层），且后者 ≤ 前者。例如并发上限 50，连接池设 limit=30。

如何避免 DNS 成为隐性拖累？

默认情况下，aiohttp 每次请求都会调用系统 getaddrinfo，对同一域名反复解析。在抓取 1000 个 example.com 页面时，这部分开销可占总耗时 15%~30%。

启用 DNS 缓存：TCPConnector(ttl_dns_cache=300)（单位秒），300 秒内重复域名直接走缓存
更进一步，加装 aiodns：它用 C 实现异步 DNS 查询，绕过系统阻塞调用；安装后传入 resolver=AsyncResolver()
注意：Windows 上 aiodns 需要额外装 pycares，Linux/macOS 直接 pip install aiodns

不配 DNS 缓存时，await session.get("https://httpbin.org") 可能卡在 resolve 阶段长达 1.2 秒；配了之后稳定在 2~5ms。

python-script-generator

快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。

下载

连接复用失效的三个典型配置错误

很多人以为只要用了 aiohttp 就自动复用连接，其实必须满足三个条件，缺一不可：

目标服务器支持 HTTP/1.1 + Connection: keep-alive（绝大多数现代网站都支持）
ClientSession 复用同一个实例，而不是每次请求都 ClientSession() 新建一个
TCPConnector 的 force_close=False（默认值，但显式写出更安全）

错误写法示例：

async def bad_fetch(url):
    async with aiohttp.ClientSession() as session:  # ❌ 每次新建 session → 连接池失效
        async with session.get(url) as resp:
            return await resp.text()

正确写法是把 session 提到外层循环或作为参数传入，确保整个生命周期复用。

超时与重试必须分层设置

只设 ClientTimeout(total=10) 是不够的。网络请求实际包含多个阶段：DNS 解析、TCP 连接、TLS 握手、发送请求、等待响应头、接收响应体。任一环节卡死，都会拖垮整个协程。

分层超时更可靠：ClientTimeout(sock_read=5, sock_connect=3)，避免某个连接卡在握手阶段占着信号量不放
重试不能无脑 await asyncio.sleep(1)：要指数退避（0.5 * (2 ** attempt)），并区分错误类型——DNS 失败重试有意义，404 错误重试纯属浪费
关键点：ClientSession 内置的 raise_for_status() 不会触发重试，必须自己 if resp.status >= 400: 判断后手动抛异常

最容易被忽略的是：当 sock_connect 超时时，底层 socket 可能已进入 TIME_WAIT 状态，此时连接池不会立即回收该连接，需靠 keepalive_timeout 参数控制回收时间（默认 15 秒，可设为 5 秒加速复用）。