Kafka + Scrapy 实现分布式爬虫的核心是解耦任务分发与结果收集：Scrapy 负责解析和调度，Kafka 承担跨节点任务分发、去重缓冲与结果归集，支持横向扩展、防重复抓取和状态持久化。
用 Kafka + Scrapy 实现分布式爬虫，核心是把任务分发和结果收集从 Scrapy 原生单机模型中解耦出来。Scrapy 负责解析逻辑和请求调度，Kafka 负责跨机器的任务分发、去重缓冲与结果归集，这样就能横向扩展多个爬虫节点，同时避免重复抓取和状态丢失。
为什么选 Kafka 而不是 Redis 或 RabbitMQ？
Kafka 的持久化日志、高吞吐、分区有序、消费者组机制，特别适合爬虫场景：
- 任务队列不丢：爬虫节点宕机重启后，未消费的任务仍在 topic 中，自动继续处理
- 支持多消费者组：一个 group 消费 URL 队列做抓取，另一个 group 消费结果 topic 做清洗或入库，互不干扰
- 分区键（如 URL 的 hash）可保证同一域名请求落到同一 partition，便于限速和会话复用
- 天然支持积压监控（lag）、消息回溯、按时间/偏移量重放，运维排查更直观
Scrapy 改造关键点：替换 Scheduler 和 Pipeline
原生 Scrapy 的内存队列和文件 pipeline 必须替换成 Kafka 接口：
-
Scheduler：继承
scrapy.core.scheduler.Scheduler，用kafka-python消费 URL topic（如spider_urls），将 Request 序列化为 JSON（含 url、callback、meta 等字段）入队；去重逻辑移到 Kafka consumer 端或前置用 BloomFilter+Redis -
Downloader Middleware：在
process_request中注入 UA、代理、延迟控制，避免所有节点共用同一 IP 或触发反爬 -
Item Pipeline：不再写本地 JSON/CSV，而是序列化 item 后发送到
spider_itemstopic，由独立服务消费入库或转存 ES
部署结构与典型流程
最小可行分布式架构包含三类角色：
立即学习“Python免费学习笔记（深入）”；
-
Seed Producer：初始 URL 生产者（如从数据库或文件读取种子链接），发往
spider_urls - Scrapy Workers：多个 Docker 容器或服务器运行修改后的 Scrapy Spider，各自作为 Kafka consumer group 成员拉取 URL 并抓取
-
Item Consumer：Python/Go 服务订阅
spider_items，做去重、清洗、写 MySQL/Elasticsearch，失败时可发回死信 topic 重试
整个流程无中心调度节点，靠 Kafka 的分区和 offset 自动负载均衡，增减 worker 只需启停容器，无需改代码。
避坑提醒：实际容易出问题的细节
不是接入 Kafka 就万事大吉，这几个点必须提前处理：
- Kafka 消息体别超 1MB：URL 请求本身不大，但带上 cookies、headers、body 可能超标，建议只传必要字段，详情在 worker 内部补全
- Scrapy 的
start_requests不再生效：所有入口 URL 必须走 Kafka，启动时让 worker 订阅即可，不用硬编码 seeds - Request meta 中的函数对象（如 callback 引用）不能序列化：统一用字符串标识回调方法名（如
"parse_list"），worker 内部用 getattr 动态调用 - 网络异常或解析失败的 Request，要发回 retry topic（带重试次数、下次投递时间），避免无限循环或卡死
不复杂但容易忽略。
