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_items topic，由独立服务消费入库或转存 ES

部署结构与典型流程

最小可行分布式架构包含三类角色：

• 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（带重试次数、下次投递时间），避免无限循环或卡死

不复杂但容易忽略。