Scrapy并发与延迟设置详解

本文深入解析了Scrapy中核心并发控制参数CONCURRENT_REQUESTS的本质与常见误区，明确指出它仅限制“同时发出的请求数”，而非响应处理数或QPS，并澄清其与DOWNLOAD_DELAY、AUTO_THROTTLE、域名/IP限频机制之间的正交性、优先级和协同逻辑；文章直击开发者高频困惑——如“设了CONCURRENT_REQUESTS却没效果”“多个Downloading日志共存”“开了per-domain仍被封”“concurrent_requests=0是否异常”等，结合多Spider、中间件干扰、代理策略、随机延迟防反爬等真实场景，给出可落地的配置组合建议与调试方法，帮你避开坑、控节奏、稳爬取。

CONCURRENT_REQUESTS 设置后没效果？先看它管的是哪层并发

Scrapy 的 CONCURRENT_REQUESTS 控制的是「同时发出的请求数」，不是「同时处理的响应数」，更不等于「每秒请求数」。它只作用于 downloader queue 中正在被 downloader 处理的请求——也就是说，爬虫生成了 100 个 Request，但真正发出去的最多只有 CONCURRENT_REQUESTS 个，其余排队等空位。

常见错误现象：CONCURRENT_REQUESTS = 1 却看到日志里多个 Downloading 同时出现。这通常是因为：你开了多个 spider（比如用 scrapy crawl spider1 & scrapy crawl spider2），或者用了 CrawlSpider 规则触发了多路并行解析，又或者中间件/扩展偷偷发了额外请求（如自动重试、AJAX 渲染插件）。

• CONCURRENT_REQUESTS 是全局设置，对所有 spider 生效；若需 per-spider 控制，改用 custom_settings 字典里的 'CONCURRENT_REQUESTS': 2
• 它和 DOWNLOAD_DELAY 是正交关系：延迟影响「单个 downloader slot 发出下个请求前要等多久」，而并发数影响「多少个 slot 能同时干活」
• 如果启用了 AUTO_THROTTLE_ENABLED = True，CONCURRENT_REQUESTS 会被动态压制——此时设再大也没用

DOWNLOAD_DELAY 和 RANDOMIZE_DOWNLOAD_DELAY 怎么配才不被封

单纯设 DOWNLOAD_DELAY = 1 每次都卡死 1 秒，反而容易暴露爬虫特征。真实站点喜欢用固定间隔做反爬识别，所以 Scrapy 默认开启 RANDOMIZE_DOWNLOAD_DELAY = True（除非你显式关掉），让实际延迟在 0.5 * DOWNLOAD_DELAY 到 1.5 * DOWNLOAD_DELAY 之间随机浮动。

使用场景：爬新闻站或电商详情页这类对频率敏感的目标时，建议组合使用：

• DOWNLOAD_DELAY = 1.5 —— 基准间隔拉长，避开多数默认限速阈值（如 Nginx 的 limit_req）
• 保持 RANDOMIZE_DOWNLOAD_DELAY = True（默认值，不用写）
• 加 AUTOTHROTTLE_START_DELAY = 1 和 AUTOTHROTTLE_MAX_DELAY = 3，让 Scrapy 自动根据响应时间微调节奏

注意：DOWNLOAD_DELAY 对 start_urls 里的初始请求也生效，但对 errback 或 callback 中手动 yield Request(...) 出来的请求同样有效——这点常被忽略，导致误以为“新请求没走延迟”。

为什么开了 CONCURRENT_REQUESTS_PER_DOMAIN 还是被封

CONCURRENT_REQUESTS_PER_DOMAIN 是按域名隔离并发的开关，但它只限制「同一 netloc（如 example.com）下的并发请求数」，不防 IP 封禁。如果你用的是代理池或公司出口 IP，多个域名请求全打到同一个 IP 上，目标站看的是源 IP 总频次，这时候 CONCURRENT_REQUESTS_PER_DOMAIN 就形同虚设。

参数差异：

• CONCURRENT_REQUESTS_PER_DOMAIN = 2：对 a.example.com 和 b.example.com 分别限 2，并非总共 2
• CONCURRENT_REQUESTS_PER_IP = True 才真正按 IP 统计（需配合 CONCURRENT_REQUESTS_PER_DOMAIN = 0 或更大值，否则后者优先级更高）
• 如果用了 scrapy-rotating-proxies 类插件，记得关掉 CONCURRENT_REQUESTS_PER_IP，否则可能因代理 IP 解析不稳定导致并发归零

性能影响：开 CONCURRENT_REQUESTS_PER_IP 会增加 downloader 内部路由判断开销，小规模爬取几乎无感，但万级 URL 下建议压测对比。

DEBUG：日志里看到 concurrent_requests=0 是怎么回事

这是 Scrapy 在等待 DOWNLOAD_DELAY 或 AUTOTHROTTLE 放行时的真实状态，不代表卡死。典型错误现象：设置 CONCURRENT_REQUESTS = 8，但日志一直显示 concurrent requests: 0，几秒后突然跳到 8——说明所有 slot 都在等延迟到期。

排查步骤：

• 检查是否误设了极大 DOWNLOAD_DELAY（比如 60），且 RANDOMIZE_DOWNLOAD_DELAY = False
• 确认没在 parse 中用 time.sleep() 或同步 HTTP 请求阻塞了 Twisted reactor
• 看 scrapy version -v 输出，老版本（AUTOTHROTTLE 的初始化有 bug，可能导致初始 delay 被设成 inf
• 临时加 LOG_LEVEL = 'DEBUG'，搜日志里 schedule delay 相关行，定位具体在哪卡住

最容易被忽略的一点：某些中间件（尤其是自定义的 process_request）如果抛了未捕获异常，会导致该请求直接丢弃、slot 不释放，表现就是并发数卡在某个值不上不下——务必确保所有中间件都有 try/except 包裹。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。