分布式爬虫调度核心是任务分发、负载均衡、故障恢复与去重协同；采用一致性哈希分片降低迁移成本，结合布隆过滤器本地去重、Gossip同步摘要、etcd最终校验；动态负载感知优先派发至低负载节点，并通过etcd租约实现宕机任务安全续爬。
Go语言编写分布式爬虫集群时，调度策略的核心是解决任务分发、节点负载均衡、故障恢复和去重协同四大问题。Go的并发模型（goroutine + channel）和轻量级网络库天然适合构建高吞吐、低延迟的调度系统，但关键不在语言特性，而在策略设计是否贴合分布式场景的真实约束。
任务分片与一致性哈希调度
避免中心化任务队列成为瓶颈，需将URL空间预先分片。常用做法是对URL做哈希（如FNV-1a），再对节点数取模，但节点增减会导致大量任务重映射。改用一致性哈希可显著降低迁移成本：将每个Worker节点映射到哈希环多个虚拟节点，URL哈希后顺时针找到首个节点即为归属。Go中可用hashicorp/memberlist或轻量实现（如github.com/cespare/xxhash + 环结构）。
- 虚拟节点数建议设为100–200，平衡分布均匀性与内存开销
- 新增节点时仅迁移其邻近区间的URL，旧节点无需主动推送任务
- 配合布隆过滤器（Bloom Filter）在节点本地快速判断URL是否可能已抓取，减少跨节点查重RPC
动态负载感知的任务派发
静态哈希无法应对节点实际负载差异（如CPU飙高、网络延迟突增）。调度器应周期采集各Worker指标（goroutine数、待处理URL队列长度、最近10秒平均响应时间），加权生成实时负载分值。Go中可用prometheus/client_golang暴露指标，或通过gRPC双向流上报。
- 任务派发时优先选择负载分值最低的3个节点，再按一致性哈希结果从中选取——兼顾稳定性与弹性
- 对高优先级种子URL（如首页、RSS源），允许“插队”跳过负载检查，直接推送给空闲度最高的节点
- Worker上报负载时附带自身时间戳，调度器丢弃超过5秒的陈旧数据，防止误判
去重与状态协同的最小化通信
分布式去重不能依赖单点Redis或MySQL，否则成性能瓶颈和单点故障源。推荐分层策略：本地布隆过滤器（拦截95%+重复URL）→ 节点间Gossip协议同步近期指纹摘要 → 关键URL写入分布式KV（如etcd）做最终校验。
立即学习“go语言免费学习笔记（深入）”；
- 布隆过滤器使用可扩展版本（如Cuckoo Filter），支持动态扩容，Go有github.com/seiflotfy/cuckoofilter
- Gossip每30秒交换一次最近1万条URL的xxHash摘要（64位），不传原始URL，节省带宽
- etcd仅存高频种子页或深度≤2的URL，设置TTL为2小时，避免存储膨胀
故障转移与任务续爬保障
Worker宕机时，未完成任务不能丢失。关键不是“立刻重发”，而是“安全移交”：调度器检测到心跳超时（如连续3次gRPC Keepalive失败），先标记该节点为“待清理”，暂停向其派发新任务；等待30秒，若仍无响应，则扫描其最后上报的待处理队列快照，将其中URL重新哈希分发。
- 每个Worker定期将本地待抓URL列表（限前500条）加密后写入etcd临时路径，带Lease TTL=60秒
- 调度器监听所有Worker的etcd租约事件，租约过期即触发迁移逻辑
- 重发任务时附加retry_count字段，超过3次自动降级为低优先级，防止雪崩
