Redis通过BRPOP阻塞式消费、URL指纹去重、SET任务标记+EXPIRE防死锁、etcd动态配置同步及redsync分布式锁，实现跨节点任务可见、原子消费与高可用容错。
用 Redis 实现节点间 URL 任务同步
分布式爬虫最常卡在「多个节点重复抓同一 URL」或「某节点宕机后任务丢失」——核心是任务队列没做到跨节点可见且原子消费。Redis 的 LPOP/RPOP 配合 BRPOP 是最轻量、最可控的方案，比 Kafka 更适合中小规模爬虫系统。
常见错误现象：BRPOP 超时返回空值却没重试；多个 worker 同时 LPOP 导致任务漏取；没设 EXPIRE 导致死任务堆积。
- 必须用
BRPOP替代LPOP，避免轮询浪费 CPU（BRPOP crawl_queue 0表示阻塞直到有任务） - 每个任务入队前加唯一指纹（如
sha256(url)），写入前先用EXISTS检查，防重复入队 - 任务出队后立即用
SET task:标记处理中，超时自动释放，供失败重试逻辑识别sha256(url)processing EX 300 - worker 完成后删掉该
task:xxxkey，失败则由 watchdog 定期扫描过期 key 并重新入队
用 etcd 实现节点状态与配置实时同步
当你要动态增减爬虫节点、切换代理池、或热更新 User-Agent 池时，靠文件 + rsync 或数据库轮询太慢且易冲突。etcd 的 watch 机制能真正实现「一改全知」。
典型场景：某节点发现目标网站封了当前 IP 段，需立刻通知所有节点切换代理策略；或调度中心下发新种子 URL 列表。
- 节点启动时，用
Put写入自身注册信息（如/nodes/worker-01→{"ip":"10.0.1.5","status":"up","load":12}），并设置 TTL（Lease） - 调度中心监听
/nodes/前缀变化，用Watch接收 add/update/delete 事件，实时调整任务分发权重 - 配置项统一存在
/config/user_agent_pool，节点用Get初始化，并起 goroutine 持续Watch变更，收到后热 reload - 避免直接监听根路径，watch 范围越细越好，否则大量事件会压垮 client 连接
用 redsync 实现关键操作的分布式互斥
不是所有操作都需要强一致，但以下几类必须加锁：去重布隆过滤器的批量更新、结果写入 MongoDB 前的 schema 检查、代理池健康度统计汇总。这些地方一旦并发写乱，数据就不可逆损坏。
redsync 是目前 Go 生态里对 Redlock 算法封装最稳的库，比手写 SETNX + Lua 更可靠。
- 锁名要带业务上下文，比如
bloom_update:20260427而不是lock，避免不同模块误抢 - 务必设
Expiry（建议 ≥ 单次操作最大耗时 × 2），防止节点崩溃导致锁永远不释放 - 获取锁失败时不要死等，应退避重试（如指数退避
time.Sleep(100 * time.Millisecond ），否则雪崩 - 锁粒度宁小勿大：对「单个 URL 去重校验」加锁毫无意义，但对「全量布隆位图刷新」必须加
别忽略本地缓存与最终一致性边界
很多人以为「用了 etcd 就万事大吉」，结果发现节点读取配置总有几百毫秒延迟，或布隆过滤器本地副本和 Redis 里不一致。这不是 bug，是分布式系统的天然代价。
真实系统里，90% 的读操作不该直连 etcd/Redis，而应走本地 cache + 定期 refresh + watch 更新三重保障。
- 用
bigcache或freecache存本地布隆过滤器快照，每 30 秒从 RedisGETBIT批量同步一次，再结合 etcd watch 触发强制 reload - etcd 的 watch 可能丢事件（网络抖动时），所以必须搭配定期全量拉取（如每 5 分钟
Get一遍/config/下所有 key） - 节点重启时，不能只依赖 etcd 注册，还要主动从 Redis 任务队列
LRANGE拉最近 100 条未完成任务补位，否则冷启动期间大量任务积压
同步从来不是「让所有节点时刻一样」，而是「让每个节点知道它该信谁、何时该信、信错了怎么兜住」。越早接受这个前提，越少在凌晨三点被告警电话叫醒。
