Celery通过Broker调度爬虫任务函数实现异步执行，配合Celery Beat定时触发、Redis去重、幂等设计、超时控制及Flower监控告警，构建可靠自动化爬虫系统。
用 Celery 实现爬虫任务的异步调度
爬虫任务常需要错峰执行、避免阻塞主线程，Celery 是最成熟的 Python 分布式任务队列方案。它把爬虫逻辑封装为可远程调用的任务函数，交由 worker 进程异步执行，主程序只负责发任务、查状态。
关键点：
- Celery 不直接运行爬虫，而是调度“带爬虫逻辑的函数”，所以先写好可独立运行的爬虫函数（如 fetch_news()），再用 @app.task 装饰
- Broker（如 Redis 或 RabbitMQ）是任务中转站，必须提前启动并配置到 Celery app 中
- Worker 启动后持续监听 Broker，一有新任务就拉取、执行、回传结果
- 推荐使用 Redis：轻量、易部署，适合中小规模爬虫调度
让爬虫按计划自动运行：Celery Beat 定时触发
Celery 自带的定时调度器 Celery Beat 可替代 crontab，统一管理所有周期性爬虫任务。它不是单独进程，而是作为 Celery 的一个组件，定期将预设任务推送到 Broker。
配置要点：
立即学习“Python免费学习笔记（深入）”；
- 在 Celery 配置中启用 beat_schedule，例如每 15 分钟抓一次天气数据：
'fetch-weather': { 'task': 'tasks.fetch_weather', 'schedule': 900.0 } - 定时单位是秒，支持 float 类型；也支持 crontab(minute='*/15') 等更灵活写法
- Beat 和 Worker 可部署在同一台机器，也可分离——Beat 单独一台，Worker 多台横向扩展
- 注意时区：默认 UTC，国内项目建议显式设置 timezone = 'Asia/Shanghai'
防止重复抓取与任务幂等性设计
定时任务 + 异步执行容易引发重复请求，尤其当网络延迟或 worker 重启时。不能依赖“调度不重”来保证唯一性，而要在任务内部做控制。
实用做法：
- 每个爬虫任务开头加去重检查：比如用 Redis 的 SETNX 记录本次任务 ID（如 task:weather:20240520_1030），成功才继续，失败直接退出
- 数据库写入前先查是否存在同源 URL 或时间戳，避免冗余存储
- 任务函数本身设计为幂等：多次执行结果一致，不产生副作用（如不重复发通知、不重复更新计数器）
- 给关键任务加超时限制：@app.task(soft_time_limit=300, time_limit=360)，防止单个爬虫卡死整个 worker
监控与故障恢复：让自动化真正可靠
无人值守的爬虫系统一旦出错容易静默失败。需加入基础可观测能力。
最小可行方案：
- 用 flower（Celery 官方 Web 监控工具）实时看任务队列、worker 状态、执行耗时和异常堆栈
- 任务失败时主动发告警：在 @app.task(autoretry_for=(Exception,), retry_kwargs={'max_retries': 3}) 基础上，覆盖 on_failure 方法，用微信/钉钉机器人推送错误摘要
- 记录结构化日志：用 Python logging + JSON 格式输出，字段包含 task_id、url、status、duration，方便 ELK 或 Grafana 分析
- 对长期无响应的 worker，可在启动脚本中加健康检查（如 ping Redis + 检查 pidfile），异常时自动重启
