直接用Celery+Redis做调度器会丢任务，因Redis不支持消息持久化重投且Celery默认ack机制无法回滚崩溃worker的未确认任务；需改用etcd等带租约能力的存储，结合CAS实现任务抢占、三态管理与心跳监听。
为什么直接用 Celery + Redis 做调度器会丢任务
很多团队第一反应是拿 Celery 搭配 Redis 当消息队列，但实际跑起来后常出现「爬虫节点突然宕机，正在处理的任务永久丢失」。根本原因是 Celery 默认的 acknowledgement 机制在 worker 进程崩溃时无法回滚未确认任务——尤其是当 task_acks_late=True 但 broker（如 Redis）本身不支持消息持久化重投时，任务就真没了。
真正可用的方案必须满足两个硬条件：任务状态可查、执行权可抢断。这意味着不能只靠消息队列，得引入分布式协调原语。
- 必须用带租约（lease）能力的存储，比如
etcd或ZooKeeper，而不是纯缓存型的Redis - 每个爬虫节点启动时要注册自己为「活跃调度者」，并持续刷新心跳；超时未刷，则其他节点可安全接管其待执行队列
- 任务表不能只存「待执行」和「已完成」两种状态，得有
pending（已分配未开始）、running（已开始）、failed（失败需重试）三态
如何用 etcd 实现任务抢占式分配
etcd 的 Lease + CompareAndSwap (CAS) 是实现抢占的关键。你不该把任务 ID 直接塞进一个共享 list 然后 pop，而应该让每个节点尝试用 CAS 把某个任务的 owner 字段从空字符串改成自己的节点 ID，且这个操作必须绑定在一个有效 lease 下。
示例逻辑片段：
def claim_task(etcd_client, task_id, node_id, lease_ttl=30):
lease = etcd_client.lease(ttl=lease_ttl)
# 尝试将 /tasks/{task_id}/owner 从 "" 改成 node_id，仅当当前值为空且 lease 有效
status = etcd_client.transaction(
compare=[etcd_client.transactions.value('/tasks/%s/owner' % task_id) == ''],
success=[etcd_client.transactions.put('/tasks/%s/owner' % task_id, node_id, lease=lease)],
failure=[]
)
return status[0] # True if claimed
- 失败不等于没任务，而是说明别的节点刚抢走，应立即重试下一条
- lease TTL 必须明显短于单个任务最长预期耗时（比如任务最长 120 秒，lease 设为 45 秒），否则故障节点“假死”太久，新节点不敢接手
- 务必在任务完成时显式调用
lease.revoke()，避免 lease 泄漏拖慢集群清理速度
如何避免「脑裂」导致重复抓取同一 URL
当网络分区发生时，两个调度节点可能各自认为对方已下线，同时对同一批任务发起抢占。这时候光靠 owner 字段不够，得加一层幂等性兜底。
核心做法是在任务元数据里嵌入一个由 URL + 抓取参数哈希生成的 dedup_key，所有爬虫节点在真正发起 HTTP 请求前，先向共享存储（如 etcd 或 PostgreSQL）写入一个带 TTL 的 key：/dedup/{dedup_key}，值为当前节点 ID 和时间戳。只有写入成功（即 key 不存在）才允许继续请求。
- 这个写入操作也必须用 CAS 或原子 set-if-not-exists，
Redis的SETNX可用，但要注意它不支持 TTL 原子设置，得配合EXPIRE—— 中间若 crash 就可能留下永久锁 - 更稳的做法是统一走
etcd的Putwith lease，天然支持自动过期 - 别依赖爬虫中间件层做去重，那是事后补救；调度层的去重才是第一道防线
心跳检测延迟太高？别只依赖定时轮询
常见陷阱是每个节点每 5 秒往 /nodes/{node_id}/heartbeat 写一次时间戳，然后由主调度器定时扫表判断超时。这会导致故障发现延迟高达 5–10 秒，对秒级时效要求的爬取场景不可接受。
正确做法是让所有节点监听同一个前缀路径（如 /nodes/），利用 etcd 的 watch 机制实时感知增删。一旦发现某节点的 heartbeat 键被删除（lease 过期自动删），立刻触发任务回收流程。
- watch 必须设为
recursive=True，且 handler 要能处理连接中断重连，不能因一次网络抖动就退出监听 - 回收任务时，不能直接把
running状态的任务改回pending—— 得先检查该任务是否已在目标节点上完成（比如通过回调上报或结果落库状态），否则可能重复执行 - 建议给每个任务加一个
version字段，每次状态变更都递增，回收时用 CAS 校验 version，防止覆盖新写入的状态
这套机制跑起来之后，最易被忽略的是 lease 续期的稳定性——不是简单地「每隔 N 秒 renew 一次」，而是要在任务执行关键路径里插桩，在可能阻塞的位置（比如下载前、解析后）主动 check 并 refresh lease，否则长耗时任务会让 lease 提前过期。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
