Scrapy本身不支持分布式，必须借助scrapy-redis替换SCHEDULER和DUPEFILTER_CLASS，通过Redis实现跨机器任务队列共享与全局去重，所有节点共用同一REDIS_URL，start_urls需手动推入Redis对应list，各实例争抢消费URL并自动负载均衡。
Scrapy本身不支持分布式，别硬凑
Scrapy是单机异步爬虫框架，scrapy crawl 启动后所有调度、去重、下载都在一个进程里完成。强行用多台机器跑多个Scrapy实例，会重复抓取、状态不一致、去重失效——这不是分布式，是“撞库式并发”。真要分布式，得靠外部组件接管关键环节。
用Redis做Scheduler和DupeFilter的替代方案
核心是把Scrapy默认的内存队列和集合换成Redis。需要替换两个关键组件：SCHEDULER 和 DUPEFILTER_CLASS。官方Scrapy不提供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://127.0.0.1:6379"
- 所有节点共用同一Redis实例，
start_urls写入Redis的spider:start_urlslist，各节点从该list弹出URL；去重指纹存于Redis set，自动跨进程共享
避免Master-Slave模式下常见的启动顺序陷阱
常见错误是先启动多个Spider实例，再往Redis塞URL——结果部分实例因没监听到初始URL而直接退出。正确顺序必须是：
- 确保Redis服务已运行且可连通（用
redis-cli ping验证） - 用
lpush spider:start_urls "https://example.com"手动推入至少1个URL（或用脚本批量推） - 再启动任意数量的Scrapy实例（命令相同：
scrapy crawl myspider） - 所有实例会争抢pop URL，自动负载均衡，但需注意：若某实例崩溃，其正在处理的request不会回滚，除非启用
SCHEDULER_FLUSH_ON_START = False并配合重试中间件
去重粒度与性能取舍：URL vs request fingerprint
scrapy-redis 默认按完整 Request 对象生成fingerprint（含method、body、headers等），比单纯URL去重更严格，但也更耗资源。如果业务只需URL级去重，可在自定义DupeFilter中简化逻辑：
立即学习“Python免费学习笔记（深入）”；
def request_fingerprint(self, request):
return hashlib.sha1(request.url.encode()).hexdigest()
但要注意：这样会漏掉POST不同body、或带不同Cookie但同URL的请求。实际项目中，建议保留默认fingerprint，再通过 priority 和 meta 控制调度优先级，而非牺牲去重精度。
真正难的是任务失败恢复和状态监控——Redis里没有“正在处理中”的显式标记，只能靠超时+重试+日志聚合来逼近可靠性。这点容易被低估。
