scrapy-redis实现分布式爬虫必须同时替换dupefilter_class和scheduler为redis版本，并设置scheduler_persist=true，否则去重失效或任务丢失；增量逻辑需自行在start_requests或pipeline中通过时间戳、id偏移或redis种子队列控制。
Scrapy-Redis 的 dupefilter_class 和 scheduler_class 必须同时替换
只换其中一个会导致去重失效或任务不入队。默认 Scrapy 用内存去重（RFPDupeFilter）和内存调度器，跨机器后这些状态无法共享，必须统一指向 Redis 实现：
DUPEFILTER_CLASS = 'scrapy_redis.dupefilter.RFPDupeFilter'SCHEDULER = 'scrapy_redis.scheduler.Scheduler'- 必须设置
SCHEDULER_PERSIST = True，否则爬虫结束时 Redis 中的待抓取队列（spider_name:requests）会被清空
漏掉 SCHEDULER_PERSIST = True 是最常见导致“重启后从头开始”的原因。
增量逻辑得靠你自己控制，Scrapy-Redis 不自动判断“新链接”
它只保证同一请求不重复入队，但不会帮你比对数据库、时间戳或版本号。要真正增量，你得在 start_requests() 或 pipeline 中做判断：
- 从数据库/文件读取上次最大
updated_at或最后爬过的 ID - 构造带时间范围或偏移参数的起始 URL，比如
https://api.example.com/items?since=2024-05-01 - 或者用
scrapy_redis.spiders.RedisSpider从 Redis 的 list 中动态取种子（此时你要自己维护这个 list 的增量更新逻辑）
别指望 RedisSpider 自动给你增量——它只是把起始 URL 源从代码挪到了 Redis，源头数据怎么更新，还是你负责。
提示词大师-python版
下载
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
多个爬虫实例共用一个 Redis key 前缀时，注意 REDIS_PARAMS 的 db 和 prefix
默认所有爬虫用 scrapy:requests 和 scrapy:dupefilter，如果 A 项目和 B 项目混在一个 Redis 实例里，会互相干扰：
- 显式指定
REDIS_URL = 'redis://localhost:6379/1'隔离 DB - 或配置
REDIS_PARAMS = {'prefix': 'myproject:'}，这样队列变成myproject:requests - 检查 Redis 中实际 key：用
redis-cli KEYS "myproject:*"确认没有残留旧任务
线上常因前缀没隔离，导致测试爬虫把生产队列刷没了。
scrapy_redis.queue.SpiderQueue 和 SpiderPriorityQueue 的选择影响重试与顺序
默认用 SpiderQueue（FIFO），但如果需要按优先级或深度重试失败请求，得切到 SpiderPriorityQueue 并确保 request 带 priority 参数：
- 在
make_requests_from_url或yield scrapy.Request(..., priority=10)中设值 -
SpiderPriorityQueue底层依赖 Redis 的 sorted set，性能略低于 list，但支持优先级语义 - 若用
SpiderStack（LIFO），可能让深层页面被反复抓，不适合广度优先场景
队列类型一旦选错，爬取路径和重试行为就不可控，调试时很难回溯——改之前先确认你的业务是否真需要优先级。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
