目录
1. Celery 核心架构
1.1 整体架构说明
Celery 是分布式异步任务队列，用于处理耗时操作，不阻塞主流程，是 Python 生态最常用异步方案。
1.2 Broker（任务消息队列）
- 作用：接收任务、排队、分发任务给 Worker
- 常用选型：
- Redis：部署简单、速度快，中小型项目首选
- RabbitMQ：更稳定、消息可靠性高，大型项目/金融支付推荐
- 必须开启持久化，防止重启丢失任务
1.3 Worker（任务执行单元）
- 真正执行异步任务的进程
- 可以多机器、多进程扩容
- 负责：取任务 → 执行 → 上报结果
- 一个 Worker 可同时并发执行多个任务
1.4 Beat（定时任务调度器）
- 用于定时任务，如：每日统计、周报、定时推送
- 定时向 Broker 发送任务
- 分布式环境需保证单节点运行，避免重复执行
1.5 Backend（结果存储）
- 存储任务执行结果、状态、返回值
- 常用：Redis、MySQL、MongoDB
- 不需要结果时可关闭，提升性能
2. Celery 典型使用场景
2.1 报告生成 / PDF / 大文件导出
- 基因报告、体检报告、检测报告生成
- Word 转 PDF、加密、加水印
- 万条数据 Excel 导出
- 特点：耗时、阻塞、必须异步
2.2 定时统计与消息推送
- 每日/每周业务统计
- 短信、邮件、钉钉、微信推送
- 订单超时自动关闭
2.3 第三方接口调用与数据同步
- 对接阿里健康、天猫、饿了么、支付平台
- 跨系统数据同步
- 批量拉取、推送、回调处理
- 特点：不可靠、可能超时、需要重试
2.4 你的项目可背诵场景
- NGS 基因报告自动生成
- 送检系统报告异步生成
- 大文件流式导出
- 定时数据统计与通知
3. 任务堆积问题
3.1 什么是任务堆积
大量任务进入队列，但 Worker 消费速度跟不上，队列越来越长，任务延迟执行。
3.2 产生原因
- 任务执行太慢（IO 慢、SQL 慢、第三方慢）
- Worker 数量太少
- 突然流量暴涨
- 任务死循环/异常卡死
3.3 如何排查
- 查看队列长度
- 监控 Worker 状态
- 查看任务执行日志
- 分析慢任务
3.4 解决方案
- 水平扩容 Worker（最直接）
- 拆分大任务为多个小任务
- 优化任务逻辑：SQL、缓存、减少IO
- 任务优先级：重要任务优先执行
- 异常捕获，避免卡死
4. 幂等性设计
4.1 什么是幂等性
同一个任务执行多次，结果与执行一次完全一致，不会产生脏数据、重复数据。
4.2 为什么需要
- 网络重传
- Worker 重启
- 任务重试
- 都会导致任务重复执行
4.3 实现方案
- 唯一任务 ID：生成唯一 task_id，执行前判断是否已执行
- 状态机判断：数据库状态位，已处理则跳过
- 数据库唯一约束：防止重复插入
- 分布式锁：执行前加锁，防止并发重复执行
4.4 必须保证幂等的场景
- 支付回调
- 订单创建
- 库存扣减
- 报告生成
- 数据同步
5. Celery 常见问题与解决方案
5.1 任务丢失
- 原因：Broker 未开启持久化、服务宕机
- 解决方案：
- Redis 开启 AOF/RDB
- RabbitMQ 持久化队列与消息
- 任务发布确认
5.2 任务重复执行
- 原因：超时、重试、网络波动
- 解决方案：幂等性设计
5.3 任务超时/阻塞
- 原因：第三方慢、数据库慢、死锁
- 解决方案：
- 异步化
- 设置超时时间
- 自动重试（最多3次）
- 失败告警
5.4 内存泄漏
- 原因：任务持有大对象、全局变量
- 解决方案：
- 任务内部创建、使用完释放
- 定期重启 Worker
6. Celery 高频面试扩展知识点
6.1 异步 vs 同步
- 同步：阻塞、等待、用户体验差
- 异步：非阻塞、立即返回、后台慢慢执行
6.2 任务优先级
- 重要任务优先处理
- 如：支付、报告 > 统计、推送
6.3 重试机制
- 自动重试
- 指数退避（1s、2s、4s、8s）
- 避免打爆第三方服务
6.4 死信队列（DLQ）
- 失败超过最大次数 → 进入死信队列
- 人工排查、手动重刷
- 生产环境必备
6.5 监控与告警
- Flower 监控 Celery
- 队列长度监控
- 任务失败、堆积、超时告警
6.6 面试必背总结
Celery = 异步 + 定时 + 分布式任务队列 核心解决：耗时任务不阻塞主线程 架构四件套：Broker → Worker → Beat → Backend 生产关键：持久化、幂等、重试、监控、不丢失、不重复
评论区