爬虫任务必须用Kafka而非Redis或RabbitMQ，因其分区并行写与时间回溯消费能力可扛住短时高密URL洪峰，并支持offset重置；需通过生产者节流、消费者解耦处理、合理分区与组名管理保障稳定。
为什么爬虫任务必须用Kafka做削峰，而不是Redis或RabbitMQ？
因为爬虫的流量峰值太“野”：整点重连、网络恢复后批量补报、分布式节点同时启动，都可能在几秒内把数万URL塞进队列。Redis List 或 RabbitMQ 默认配置扛不住这种突发写入，容易触发 ERR queue full 或连接拒绝；而 Kafka 的 log.retention.hours 和分区并行写能力，天然适合吞这种“短时高密小包”。更重要的是，Kafka 支持按时间回溯消费——当你发现某批URL解析逻辑有bug，可以直接重置 offset 重新跑，Redis 和 RabbitMQ 做不到这点。
生产者端怎么控制发送节奏，避免压垮Kafka broker？
别直接 producer.send() 往里狂塞。真实项目里必须加两层节流：
- 用
buffer.memory=32MB+batch.size=16384控制单批次大小，避免小包过多拖慢吞吐 - 在业务层加滑动窗口计数器，比如每秒最多发 500 条 URL，超了就
time.sleep(0.1)等待——这不是性能妥协，是防止max.block.ms超时导致生产者阻塞甚至崩溃 - 务必设置
retries=3和retry.backoff.ms=500，网络抖动时自动重试，比手动捕获KafkaTimeoutError更可靠
消费者端如何避免Rebalance雪崩和消息堆积？
这是最常翻车的地方。爬虫消费者一旦处理单个URL耗时超过 max.poll.interval.ms（默认5分钟），Kafka 就会把它踢出 group，触发全组 Rebalance——而此时上游还在灌数据，积压直接爆炸。
Claw Code Suite (Python-Only Edition)
下载
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
- 把
max.poll.interval.ms设为 15 分钟（900000），但更关键的是：poll() 线程只负责拉取消息，绝不做解析、请求、入库等耗时操作 - 用
asyncio.Queue或concurrent.futures.ThreadPoolExecutor把消息转发给工作线程池处理，实现 poll() 与业务逻辑解耦 - 位移提交必须严格按顺序：只在工作线程确认成功后，由 poll() 线程调用
commit(offsets=[...])提交已处理的最小连续 offset，禁止用enable.auto.commit=True
Topic 分区数和消费者数量怎么配才不浪费资源？
分区数不是越多越好。一个 Topic 设 12 个分区，却只起 3 个消费者，那 9 个分区永远空转；反过来，12 分区配 20 个消费者，多出来的 8 个根本分不到 partition，纯属占内存。
立即学习“Python免费学习笔记（深入）”；
- 先看爬虫峰值 QPS：比如稳定处理能力是 3000 URL/秒，单个消费者实测能跑 600 URL/秒 → 至少要 5 个消费者 → Topic 分区数 ≥ 5（建议设为 2× 消费者数，留扩缩容余量）
- 分区数上限受 broker 数量限制：
replication.factor=3时，最多只能设和 broker 数一样多的分区，否则部分副本无法分配 - 别忘了给每个分区预留磁盘空间——物联网场景下，一天几十亿条 URL 元数据，
log.segment.bytes设太小会导致文件碎片爆炸，建议 ≥1073741824（1GB）
group.id）的生命周期管理：测试时随手写的 group.id="test-crawler"，上线后没改，结果新旧版本消费者混在一个组里抢分区，位移互相覆盖。上线前务必检查这个字符串是否唯一且带环境标识，比如 "prod-crawler-v2"。 
