Scrapy-Redis弹性扩展依赖人工增减节点与Redis并发消费，核心是启用SCHEDULER_PERSIST=True、继承RedisSpider、使用RFPDupeFilter去重，并解决IP/UA风控、Redis单点瓶颈及连接静默问题。
Scrapy-Redis 本身不提供自动弹性扩缩容能力，所谓“弹性扩展”实际是靠人工增减爬虫节点 + Redis 队列天然支持并发消费实现的。关键不在代码多智能，而在调度逻辑是否可中断、去重是否跨节点一致、任务是否真正无状态。
scrapy-redis 调度器必须启用 SCHEDULER_PERSIST
默认情况下，SCHEDULER_PERSIST=False，爬虫退出时会清空 Redis 中的请求队列（spider:requests）和去重指纹集合（spider:dupefilter）。这会导致节点重启后任务丢失、断点续爬失败——根本谈不上扩展。
必须显式设为 True：
REDIS_URL = 'redis://192.168.1.100:6379/0' SCHEDULER = "scrapy_redis.scheduler.Scheduler" SCHEDULER_PERSIST = True DUPEFILTER_CLASS = "scrapy_redis.dupefilter.RFPDupeFilter"
注意：SCHEDULER_PERSIST=True 后，需手动清空队列（如用 redis-cli DEL spider:requests），否则下次启动会继续消费旧任务。
立即学习“Python免费学习笔记（深入）”；
爬虫类必须继承 scrapy_redis.spiders.RedisSpider
普通 scrapy.Spider 不会监听 Redis 队列，即使配置了调度器也无效。只有 RedisSpider 会在启动时从 spider:start_urls 或 redis_key 指定的 List 中读取初始 URL。
常见错误写法：
- 继承
scrapy.Spider却指望它自动从 Redis 拿任务 -
redis_key写成'my_spider:start_urls'，但没往该 key 里 push 过任何 URL - 多个节点共用同一个
redis_key，但没确认该 key 是 List 类型（LPUSH/RPOP才能保证 FIFO）
正确示例：
from scrapy_redis.spiders import RedisSpider
<p>class MySpider(RedisSpider):
name = 'news'
redis_key = 'news:start_urls' # 必须与 redis-cli LPUSH 的 key 一致</p><pre class='brush:python;toolbar:false;'>def parse(self, response):
yield {'url': response.url, 'title': response.css('title::text').get()}去重必须依赖 Redis 的 RFPDupeFilter，不能混用本地去重
如果在 settings.py 里同时配置了 DUPEFILTER_CLASS 和 HTTPCACHE_ENABLED=True，或者自定义了基于内存的去重中间件，会导致：同一 URL 在不同节点被重复抓取（因为本地去重只作用于单节点）。
确保只启用一种去重机制：
- 删掉所有自定义
DUPEFILTER_CLASS实现（除非你重写了基于 Redis 的版本） - 禁用
HTTPCACHE_ENABLED，缓存应由 Nginx 或 CDN 层处理，而非爬虫自身 - 检查
scrapy-redis版本是否 ≥ 0.7.3（旧版对 Bloom Filter 支持不完整）
Redis 去重本质是把每个 request 的指纹（fingerprint）存进 Set，所以 RFPDupeFilter 的性能直接受 Redis 网络延迟和 Set 写入速度影响；万级 QPS 场景建议搭配 redisbloom 使用布隆过滤器降载。
新增节点只需启动相同配置的爬虫实例，但要注意 IP 和 User-Agent
Scrapy-Redis 的“扩展”是无脑的：只要新机器能连上 Redis、装好相同依赖、跑起相同爬虫类，就会自动从队列取任务。但这掩盖了两个真实瓶颈：
- 所有节点共享同一出口 IP，目标站封禁风险陡增 —— 必须配合代理池或不同节点绑定不同出口 IP
- 所有节点默认用相同
USER_AGENT，易触发风控 —— 应在settings.py中用random.choice()动态设置，或通过中间件轮询 UA 池 - Redis 单点压力：当节点数 > 20 且 QPS > 500 时，
spider:requests的RPOP竞争会明显拖慢调度速度，此时应考虑 Redis 分片或改用 Redis Cluster
没有中心协调节点，也没有任务权重分配——谁抢到谁干。所以“弹性”其实是裸奔式扩展，靠的是 Redis 的吞吐兜底，而不是框架本身的调度智能。
真正容易被忽略的是：Redis 连接超时、认证失败、队列空转时的日志静默问题。很多集群看似跑起来了，实则所有节点都在反复重连 Redis 或卡在空队列等待，却没有任何报错提示。务必在 start_requests 中加日志，或用 redis-cli monitor 实时观察 key 变化。
