调度器请求堆积的根本原因是Scrapy默认内存队列无反压、不限流、不丢弃，导致Spider解析快于Downloader处理时队列指数膨胀。应替换为Redis调度器并添加入队限速中间件。
调度器请求堆积的典型表现
你看到日志里反复出现 Scheduler: queued 1245 requests，爬虫吞吐量却卡在每秒不到 1 个请求，CPU 和内存使用率长期低于 30%，但 engine.spider_idle 统计频繁触发——这不是网络慢，是调度器成了瓶颈。
根本原因在于：Scrapy 的调度器默认使用内存队列（scrapy.core.scheduler.Scheduler），当 Downloader 处理不过来时，新生成的 Request 会持续压入队列，而队列本身不反压、不限流、不丢弃。一旦 Spider 解析快于下载速度（比如静态页面 + 高并发配置），队列就指数级膨胀，最终拖垮整个引擎循环。
- 现象：响应延迟升高、
response.status正常但parse调用滞后数秒甚至分钟 - 风险：内存暴涨（尤其含 large
meta或 callback 引用）、重启后重放大量已过期请求 - 注意：
CONCURRENT_REQUESTS调高反而加剧堆积，不是“开得越大越快”
用 Redis 调度器替换内存队列
把调度器换成基于 Redis 的持久化队列，既能缓解内存压力，又能天然支持分布式和反压控制。别自己实现，直接用 scrapy-redis 提供的现成方案：
- 安装：
pip install scrapy-redis - 修改
settings.py：DUPEFILTER_CLASS = 'scrapy_redis.dupefilter.RFPDupeFilter' SCHEDULER = 'scrapy_redis.scheduler.Scheduler' SCHEDULER_PERSIST = True REDIS_URL = 'redis://localhost:6379'
- 关键区别：
SCHEDULER_PERSIST = True让队列在爬虫中断后不丢失；Redis 自带 LPOP/BRPOP 阻塞式出队，天然实现“有请求才处理”，避免空转 - 副作用：需自行管理去重指纹（
RFPDupeFilter依赖 Redis），若原逻辑用request_fingerprint自定义去重，要同步改写dupefilter类
限制调度器入队速率
即使换了 Redis，如果 Spider 生成请求太快（比如解析一页就 yield 50 个详情页），仍可能瞬间打爆下游。Scrapy 没提供原生限速 API，但可通过中间件控制：
立即学习“Python免费学习笔记（深入）”；
- 在
middlewares.py中写一个轻量级计数器：class RateLimitMiddleware: def __init__(self): self.count = 0 self.max_per_second = 20 def process_spider_output(self, response, result, spider): for r in result: if isinstance(r, scrapy.Request): self.count += 1 if self.count > self.max_per_second: time.sleep(1) self.count = 0 yield r - 启用它：
SPIDER_MIDDLEWARES = {'myproject.middlewares.RateLimitMiddleware': 543} - 比
DOWNLOAD_DELAY更精准：它限制的是“进队速率”，而非“出队间隔”，对调度器堆积更直接有效 - 慎用：
time.sleep()会阻塞 Twisted reactor，仅适合低频限速；高频场景应改用twisted.internet.defer.inlineCallbacks+deferLater
关闭不必要的调度器功能
默认调度器开启请求去重（DUPEFILTER_CLASS）和优先级队列（priority_queue），但多数爬虫并不需要。关掉能减小单次入队开销：
- 禁用去重（确认无重复 URL 场景下）：
DUPEFILTER_CLASS = 'scrapy.dupefilters.BaseDupeFilter' - 禁用优先级：
SCHEDULER_PRIORITY_QUEUE = 'scrapy.pqueues.ScrapyPriorityQueue'→ 改为'scrapy.pqueues.FifoQueue'（FIFO 更快，且避免排序开销） - 若用 Redis 调度器，
DUPEFILTER_CLASS必须保留（否则去重失效），但可关掉priority_queue：SCHEDULER_QUEUE_CLASS = 'scrapy_redis.queue.SpiderQueue' - 注意：
BaseDupeFilter不做任何去重，仅返回True，务必确认你的 Spider 已通过逻辑规避重复请求
调度器堆积本质是生产者-消费者失衡，不是调大并发就能解决的。真正有效的优化，是让调度器从“被动接收”变成“可控节流”，同时切断内存无限增长的路径。Redis 替换和入队限速这两步做完，90% 的堆积问题会立刻缓解；剩下那 10%，往往藏在 Spider 的 yield 逻辑或中间件的隐式引用里，得靠 objgraph 或 tracemalloc 往下挖。
