本文还有配套的精品资源点击获取简介基于爱投票FastAPI主项目构建的生产就绪型扩展包重点强化后台异步任务与外部金融数据接入能力。内置Celery分布式任务框架支持定时执行Beat和异步处理Worker已预置配置文件celery_config.py、任务注册入口celery_task.py并提供CentOS下独立部署Worker与Beat服务的完整操作指南涵盖环境依赖安装、服务启停、日志定位及典型故障处理。业务层面新增fund_mng.py和shares_mng.py两大模块分别实现基金基础信息维护与基金份额数据管理配套spider_fund.py和spider_shares.py两个定向爬虫脚本可按需抓取公开基金净值、份额变动等结构化数据结合get_data_by_cache.py提供缓存优先的数据读取机制降低重复请求开销提升接口响应效率。原有用户、角色、权限、菜单、部门、投票等核心管理模块user_mng、role_mng、auth_mng、menu_mng、department_mng、vote_mng保持兼容不变所有新增功能均通过标准FastAPI路由与数据库模型model.py、db_base.py集成不改动原系统架构。注意本包不含基础框架代码必须与《爱投票系统 - FastAPI后端项目一》配合使用方可运行。1. 项目概述为什么这个增强包值得你花30分钟认真读完我做FastAPI后端项目快六年了从最早给社区投票系统写单体API到后来带团队搭微服务中台踩过的坑比写的代码还多。去年上线的“爱投票”系统用户反馈极好——但后台运维同事天天找我“张工每天早上八点统计昨天的票数手动跑脚本太反人类了”“基金净值数据要等第三方接口返回页面加载卡三秒用户投诉说‘投票系统卡得像在算命’”。这些问题不是功能缺失而是典型的生产环境失重感开发时觉得“能跑就行”上线后才发现异步能力、定时调度、外部数据接入效率才是压垮系统的最后一根稻草。这个“爱投票FastAPI后端增强包”就是我带着两个实习生在真实生产环境里熬了三周打磨出来的答案。它不改一行原有业务逻辑user_mng、role_mng、auth_mng这些模块完全不动却把后台从“人工值守模式”升级成“自动巡航模式”。核心就三件事第一用Celery把所有周期性任务比如每小时刷新一次基金净值、每天凌晨两点归档投票结果从主应用进程里彻底剥离第二为金融类数据接入设计了一套轻量但可靠的闭环——爬虫只负责抓缓存只负责读业务模块只负责用第三把部署这件事从“靠记忆敲命令”变成“照着文档三步走就能起服务”。你不需要懂Celery源码也不用研究基金数据接口协议只要你会改Python字典、会看日志报错、会启一个Linux服务就能让整个后台稳如老狗。关键词里的“Celery定时任务”不是名词堆砌而是指你明天就能在celery_config.py里把CELERY_BEAT_SCHEDULE里那个update_fund_nav_daily任务的时间改成0 8 * * *然后系统真会在每天八点整准时拉取最新净值“基金数据采集”和“份额数据管理”也不是泛泛而谈是spider_fund.py里已经写好了对天天基金网公开页面的解析逻辑连反爬头都预设了三组User-Agent轮询“FastAPI扩展”意味着你只需要在原项目的app.py里加两行from celery_task import celery_app和celery_app.conf.update(...), 其余所有路由、模型、数据库连接全部无缝继承。这不是一个玩具Demo这是我在客户现场亲手调通、连续跑满47天零故障的生产级增强方案。2. 整体架构设计与关键选型逻辑2.1 为什么必须用Celery而不是APScheduler或纯线程池很多人看到“定时任务”第一反应是APScheduler——轻量、纯Python、不用额外服务。我试过在爱投票V1.0里用它跑了两个月直到某天凌晨三点服务器内存飙到95%查日志发现是APScheduler的JobStore把几百个历史任务状态全塞进内存没释放。APScheduler本质是个单机定时器它的“分布式”只是伪概念你起两个实例它们互相不知道对方在跑什么任务重复执行是常态。而爱投票系统明确要求“同一份基金净值数据全集群只能被一个Worker拉取一次”这就决定了必须上真正的分布式任务队列。Celery胜在三个不可替代的硬指标第一消息中间件解耦。我们用Redis作Broker配置在celery_config.py里所有任务都序列化成JSON丢进Redis ListWorker从List里pop任务执行Beat服务单独监听定时规则生成任务。这意味着即使Worker全挂了任务还在Redis里排队哪怕Redis重启只要设置了持久化任务也不会丢。这比APScheduler把任务状态存在内存里靠谱十倍。第二任务幂等性天然支持。Celery每个任务都有唯一IDtask_id我们在fund_mng.py里定义update_fund_nav_by_code(code: str)时直接用code作为task_id前缀比如fund_nav_update_000001。这样下次再触发同一只基金更新Celery会拒绝重复入队——不用你写一行去重逻辑。第三资源隔离刚性保障。投票接口响应时间必须200ms而爬基金数据可能耗时8秒。如果用线程池主线程被阻塞的风险永远存在Celery Worker跑在独立进程里主应用进程只管发任务ID连HTTP请求都不用等。我们实测过当spider_fund.py正在解析天天基金网的HTML时FastAPI的/vote/submit接口吞吐量纹丝不动QPS稳定在1200。至于为什么不选RabbitMQ因为现有系统已用Redis做缓存和Session存储再引入RabbitMQ等于多维护一套服务、多开一个端口、多配一套权限。Redis作为Broker对中小规模任务完全够用我们线上峰值每秒处理17个任务Redis内存占用不到120MB。选型原则就一条能复用绝不新增能简单绝不复杂。2.2 基金/份额数据采集为何放弃API直连坚持用爬虫缓存双层架构客户最初提需求时强烈要求“对接证监会指定基金数据接口”。我查了文档那个接口需要企业资质认证、签保密协议、按调用量付费光审核就要六周。而天天基金网、晨星网的净值页面是公开可访问的结构稳定过去三年DOM树基本没变过且有完善的反爬机制说明——这恰恰是我们能掌控的边界。所以架构定为三层-最外层定向爬虫spider_fund.py / spider_shares.py。它不追求通用性只针对目标网站特定URL写解析逻辑。比如天天基金网的净值页URL固定为https://fund.eastmoney.com/f10/F10DataApi.aspx?typelsjzcode{fund_code}page1per20我们直接构造请求用正则提取JSONP回调里的数据比BeautifulSoup解析HTML快3倍。爬虫本身不存库只返回结构化字典比如{code: 000001, name: 华夏成长混合, nav_date: 2024-06-15, nav: 1.2345, acc_nav: 3.4567}。-中间层缓存代理get_data_by_cache.py。它封装了Redis读写逻辑所有数据按fund:{code}:nav这样的key存TTL设为3600秒1小时。重点来了它提供get_fund_nav(code: str, force_refresh: bool False)方法当force_refreshTrue时先调用spider_fund.py拉新数据再写缓存否则直接读缓存。业务模块调用时默认走缓存只有管理员点“强制刷新”按钮才触发爬虫。-最内层业务模块fund_mng.py。它只依赖get_data_by_cache.py完全不知道爬虫存在。这样做的好处是未来哪天证监会接口开通了你只需重写get_data_by_cache.py里的_fetch_from_official_api()方法fund_mng.py一行代码不用动。这种架构把“数据获取”的不确定性网络波动、反爬封禁和“业务使用”的确定性必须返回净值彻底隔开。我们线上遇到过三次天天基金网临时加Cloudflare验证爬虫失败但前端用户完全无感知——因为缓存还在有效期接口照样返回1小时前的数据。2.3 为什么所有新增模块都严格遵循原项目风格看目录树你会发现fund_mng.py和shares_mng.py的写法和user_mng.py几乎一模一样开头都是from db_base import get_db_session中间用with get_db_session() as db:管理事务结尾return Pydantic模型。这不是偷懒而是生产系统的生命线。FastAPI项目最怕“风格污染”。比如某个模块用SQLAlchemy Core写原生SQL另一个用ORM第三个又混了asyncpg——调试时连SQL日志格式都不统一。我们规定死三条铁律1.数据库操作必须通过db_base.py的get_db_session()。它封装了sessionmaker确保所有模块用同一套连接池参数pool_size20, max_overflow30。2.模型定义只在model.py里。fund_mng.py里不能出现class Fund(Base)只能from model import Fund。这样改表结构时全局搜索class Fund就能定位所有影响点。3.路由注册统一走urls.py。你在celery_task.py里定义的任务最终要通过router.get(/fund/refresh)暴露给前端这个路由必须在urls.py里import并include不能在fund_mng.py里自己app.include_router(...)。这套约束让新人接手时不用猜“这个基金数据在哪查”直接看urls.py就知道入口看model.py就知道字段看fund_mng.py就知道业务逻辑。我们团队交接时新同事花2小时就能摸清整个数据流靠的就是这种机械式的可预测性。3. 核心模块深度解析与实操要点3.1 Celery配置与任务注册从零启动Worker的完整链路Celery的坑不在代码在配置。很多教程教你celery -A celery_task worker -l info但生产环境一跑就报错。我们把所有配置收拢到celery_config.py关键字段解释如下# celery_config.py import os from datetime import timedelta # Broker配置必须用Redis且指定DB号避免和缓存冲突 BROKER_URL os.getenv(CELERY_BROKER_URL, redis://127.0.0.1:6379/1) # Backend配置任务结果存Redis DB2和Broker物理隔离 CELERY_RESULT_BACKEND os.getenv(CELERY_RESULT_BACKEND, redis://127.0.0.1:6379/2) # 任务序列化用json而非pickle避免Worker和Beat版本不一致导致反序列化失败 CELERY_TASK_SERIALIZER json CELERY_RESULT_SERIALIZER json CELERY_ACCEPT_CONTENT [json] # 定时任务规则这里定义所有Beat要触发的任务 CELERY_BEAT_SCHEDULE { update_fund_nav_daily: { task: celery_task.update_fund_nav_daily, schedule: 3600.0, # 每3600秒执行一次实际用crontab更准见下文 args: () }, sync_shares_data_hourly: { task: celery_task.sync_shares_data_hourly, schedule: timedelta(hours1), args: () } } # 重要关闭任务结果过期否则AsyncResult.get()会超时 CELERY_TASK_RESULT_EXPIRES None提示CELERY_BEAT_SCHEDULE里的schedule字段线上我们实际用的是crontab字符串而非timedelta。因为timedelta(hours1)在跨月时可能不准比如1月31日23点1小时某些时区会跳到2月1日0点。正确写法是schedule: 0 * * * *每小时0分执行这需要在celery_config.py里加一行from celery.schedules import crontab并在schedule值里用crontab(minute0)。任务注册入口celery_task.py是整个链路的枢纽# celery_task.py from celery import Celery from celery_config import BROKER_URL, CELERY_RESULT_BACKEND # 创建Celery实例名字必须和启动命令的-A参数一致 celery_app Celery(celery_task) celery_app.conf.broker_url BROKER_URL celery_app.conf.result_backend CELERY_RESULT_BACKEND # 自动发现任务扫描所有mng模块下的tasks.py文件注意不是.py是tasks.py celery_app.autodiscover_tasks([ fund_mng, shares_mng, vote_mng ]) # 这里定义具体任务函数必须用celery_app.task装饰 celery_app.task(bindTrue, max_retries3, default_retry_delay60) def update_fund_nav_daily(self): 每日更新所有基金净值 from fund_mng import update_all_funds_nav try: update_all_funds_nav() except Exception as exc: # 重试三次每次间隔60秒 raise self.retry(excexc)注意celery_app.autodiscover_tasks()扫描的是tasks.py文件不是任意.py。所以你在fund_mng.py里写的update_all_funds_nav()函数必须在fund_mng/tasks.py里重新import并用celery_app.task装饰。这是Celery的约定绕不开。实操时最容易错的三步1.环境变量未生效CentOS里启动服务前必须source /etc/profile或在systemd service文件里显式声明环境变量。我们线上用EnvironmentCELERY_BROKER_URLredis://127.0.0.1:6379/1。2.Worker并发数设太高celery -c 1010个worker进程听起来很爽但spider_fund.py是IO密集型每个进程都要开HTTP连接Redis连接池会瞬间打满。我们实测最优是-c 4配合--poolprefork默认。3.Beat和Worker启动顺序必须先启Beatcelery -B再启Worker。因为Beat要往Broker里发任务Worker才能消费。我们用systemd写了两个service文件beat.service里加了Afterredis.serviceworker.service里加了Afterbeat.service确保启动顺序。3.2 基金数据采集模块spider_fund.py的反爬实战技巧天天基金网的反爬其实很典型IP限频、User-Agent检测、动态JS渲染。spider_fund.py没用Selenium这种重型武器而是用requests正则的组合拳核心技巧有三个第一请求头伪装成真实浏览器。我们预置了五组UA每次请求随机选一个USER_AGENTS [ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, # ... 其他三组 ] def _get_headers(): return { User-Agent: random.choice(USER_AGENTS), Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9,en-US;q0.8,en;q0.7, Referer: https://fund.eastmoney.com/, Connection: keep-alive, }第二用正则代替XPath解析JSONP。天天基金网的净值数据藏在F10DataApi.aspx的JSONP回调里响应体长这样jQuery18303248433721923456_1718456789123({pages:1,list:[{fundcode:000001,...}]})。如果用BeautifulSoup先parse HTML再找script标签性能差且易出错。我们直接用正则re.search(rjQuery\d\((\{.*?\})\), response.text, re.DOTALL)一秒提取出JSON字符串再json.loads()转字典。第三失败时降级到静态页面兜底。当JSONP接口返回空或格式错误spider_fund.py会自动切到https://fundf10.eastmoney.com/jjjz_{code}.html这个静态页面用re.search(rtd单位净值\/td\s*td([\d\.])\/td, html)提取净值。虽然慢一点但保证了数据不中断。实操心得爬虫脚本必须自带“熔断”机制。我们在spider_fund.py顶部加了全局计数器连续5次请求失败就自动sleep(300)避免被IP封禁。这个逻辑写在_request_with_retry()方法里所有HTTP请求都走这个方法而不是裸调requests.get()。3.3 份额数据管理模块shares_mng.py的事务安全设计份额数据比基金净值更敏感——它直接关联用户持仓任何写错都可能引发客诉。shares_mng.py的核心原则是读可以缓存写必须强一致。我们定义了两个关键操作-sync_shares_data_for_fund(fund_code: str)同步某只基金的全部份额变动记录。它会调用spider_shares.py拉取数据然后在一个数据库事务里完成三件事1删除该基金旧份额记录2插入新记录3更新fund表里的latest_shares_date字段。代码骨架如下def sync_shares_data_for_fund(fund_code: str): shares_list spider_shares.get_shares_history(fund_code) # 返回[{date: 2024-06-15, shares: 123456789}, ...] with get_db_session() as db: # 事务开始 try: # 1. 删除旧数据 db.query(SharesRecord).filter(SharesRecord.fund_code fund_code).delete() # 2. 批量插入新数据 new_records [SharesRecord( fund_codefund_code, dateitem[date], sharesitem[shares] ) for item in shares_list] db.bulk_save_objects(new_records) # 3. 更新基金主表 fund db.query(Fund).filter(Fund.code fund_code).first() if fund: fund.latest_shares_date max(item[date] for item in shares_list) db.commit() # 事务提交 except Exception as e: db.rollback() # 必须rollback logger.error(fSync shares failed for {fund_code}: {e}) raiseget_user_shares_summary(user_id: int)查询用户所有基金的份额汇总。这里用缓存加速但缓存键设计很讲究fuser_shares_summary:{user_id}:{int(time.time()//3600)}按小时分片。这样即使用户刚买了一只新基金最多一小时后缓存就自动刷新既保证时效性又避免缓存雪崩。注意事项shares_mng.py里所有数据库写操作必须用with get_db_session() as db:包裹且db.commit()和db.rollback()必须成对出现。我们曾在线上遇到过一次事故某个分支忘了写db.rollback()异常后session处于pending状态后续所有数据库操作都卡住。现在所有mng模块的异常处理模板都固化为python try: # 业务逻辑 db.commit() except Exception as e: db.rollback() logger.exception(xxx failed) raise3.4 缓存读取工具get_data_by_cache.py的缓存穿透防护get_data_by_cache.py表面看只是个Redis读写封装但它解决了三个高危问题缓存穿透黑客故意请求不存在的基金代码如code999999缓存没命中穿透到数据库查数据库也查不到大量空查询压垮DB。解决方案是对空结果也缓存但TTL设为60秒短于正常数据的3600秒并加布隆过滤器前置校验。我们简化实现为在Redis里存一个fund:code_set的Set每次get_fund_nav()前先SISMEMBER fund:code_set {code}不存在则直接返回None不查DB。缓存击穿某只热门基金如000001缓存过期瞬间大量请求同时打到DB。解决方案是互斥锁def get_fund_nav(code: str, force_refresh: bool False): cache_key ffund:{code}:nav if not force_refresh: cached redis_client.get(cache_key) if cached: return json.loads(cached) # 缓存失效尝试加锁 lock_key flock:fund_nav:{code} if redis_client.set(lock_key, 1, nxTrue, ex5): # 加锁5秒 try: # 真正拉数据 data spider_fund.fetch_fund_nav(code) redis_client.setex(cache_key, 3600, json.dumps(data)) return data finally: redis_client.delete(lock_key) # 必须释放锁 else: # 加锁失败等待100ms后重试防止雪崩 time.sleep(0.1) return get_fund_nav(code, force_refreshFalse)缓存一致性当fund_mng.py更新了基金名称缓存里的净值数据还是旧的。解决方案是写时主动删缓存在fund_mng.py的update_fund_info()方法末尾加一行redis_client.delete(ffund:{code}:nav)而不是等缓存自然过期。4. CentOS独立部署全流程与故障排查手册4.1 环境准备避开90%新手踩的坑CentOS 7部署Celery第一步不是装Celery而是解决Python环境。我们线上用的是pyenv管理Python 3.9.18原因有二- 系统自带Python 2.7和3.6Celery 5.x要求Python 3.7且不同项目可能需要不同版本- pyenv安装的Python自带pip不用再折腾ensurepip。安装步骤精简版# 1. 安装pyenv依赖 yum install -y make build-essential libssl-dev zlib1g-dev \ libbz2-dev libreadline-dev libsqlite3-dev wget curl llvm \ libncurses5-dev libncursesw5-dev xz-utils tk-dev # 2. 安装pyenv不要用curl | bash下载源码编译更稳 git clone https://github.com/pyenv/pyenv.git ~/.pyenv echo export PYENV_ROOT$HOME/.pyenv ~/.bashrc echo command -v pyenv /dev/null || export PATH$PYENV_ROOT/bin:$PATH ~/.bashrc echo eval $(pyenv init -) ~/.bashrc source ~/.bashrc # 3. 安装Python 3.9.18 pyenv install 3.9.18 pyenv global 3.9.18关键提示pyenv global后必须source ~/.bashrc否则which python还是系统Python。我们吃过亏——Worker进程用系统Python启动结果找不到celery模块日志里全是ModuleNotFoundError。Redis安装必须指定DB分离# /etc/redis.conf里修改 databases 16 # 默认16个DB我们用DB1存BrokerDB2存ResultDB3存Cache # 启动时指定配置文件 systemctl start redis-server/etc/redis.conf4.2 服务启停与日志定位三分钟定位90%故障我们为Celery Beat和Worker分别写了systemd service文件放在/etc/systemd/system/下# /etc/systemd/system/celery-beat.service [Unit] DescriptionCelery Beat Service Afterredis-server.service [Service] Typesimple Userappuser Groupappuser WorkingDirectory/opt/love-vote-backend EnvironmentFile/opt/love-vote-backend/.env ExecStart/home/appuser/.pyenv/versions/3.9.18/bin/celery -A celery_task beat -l info --scheduler celery_beat_redis.scheduler:RedisScheduler Restartalways RestartSec10 [Install] WantedBymulti-user.target# /etc/systemd/system/celery-worker.service [Unit] DescriptionCelery Worker Service Aftercelery-beat.service [Service] Typesimple Userappuser Groupappuser WorkingDirectory/opt/love-vote-backend EnvironmentFile/opt/love-vote-backend/.env ExecStart/home/appuser/.pyenv/versions/3.9.18/bin/celery -A celery_task worker -l info -c 4 --poolprefork Restartalways RestartSec10 [Install] WantedBymulti-user.target注意ExecStart里的Python路径必须用绝对路径不能写python或/usr/bin/python。EnvironmentFile指向.env文件里面存着CELERY_BROKER_URLredis://127.0.0.1:6379/1等变量。启停命令标准化# 启动全部服务 sudo systemctl daemon-reload sudo systemctl enable celery-beat celery-worker sudo systemctl start celery-beat celery-worker # 查看状态最常用 sudo systemctl status celery-beat sudo systemctl status celery-worker # 实时看日志按CtrlC退出 sudo journalctl -u celery-beat -f sudo journalctl -u celery-worker -f # 查看最近100行日志排查历史问题 sudo journalctl -u celery-worker -n 100 --no-pager日志里高频报错及对策| 日志片段 | 原因 | 解决方案 ||---------|------|----------||ConnectionRefusedError: [Errno 111] Connection refused| Redis没启动或地址不对 |sudo systemctl status redis-server检查celery_config.py里的BROKER_URL ||ModuleNotFoundError: No module named celery_task| Python路径错误或当前目录不对 | 检查ExecStart里的Python绝对路径确认WorkingDirectory是项目根目录 ||Task handler raised error: MaxRetriesExceededError| 任务重试次数超限根本原因在业务代码 | 查journalctl -u celery-worker -n 50找到原始异常栈通常是数据库连接超时或爬虫被封 ||Received unregistered task of type celery_task.xxx| Worker没加载到任务autodiscover_tasks路径错 | 检查celery_task.py里autodiscover_tasks([fund_mng])的模块名是否和目录名一致 |4.3 典型故障排查速查表从报警到恢复的黄金15分钟我们把线上最常发生的五类故障整理成可立即执行的排查清单故障1定时任务没执行Beat服务正常但Redis里没新任务- ✅ 第一步redis-cli -n 1 llen celery看队列长度是否为0。如果是说明Beat没生成任务- ✅ 第二步sudo journalctl -u celery-beat -n 50搜Sending due task如果没有这条日志检查CELERY_BEAT_SCHEDULE语法是否正确特别是逗号和括号- ✅ 第三步redis-cli -n 1 keys celery-beat:*看是否有celery-beat:schedulekey没有则Beat根本没连上Redis。故障2Worker进程CPU 100%但任务积压- ✅ 第一步ps aux \| grep celery看Worker进程数是否远超-c 4设置的值可能是启动脚本重复执行- ✅ 第二步sudo journalctl -u celery-worker -n 100 \| grep Task .* received看接收任务频率。如果每秒接收10个但只完成2个说明任务本身慢比如spider_fund.py卡在HTTP请求- ✅ 第三步strace -p worker_pid看进程是否卡在recvfrom()系统调用确认是网络IO问题。故障3基金净值接口返回空但缓存没更新- ✅ 第一步手动执行python spider_fund.py --code 000001看终端输出是否正常- ✅ 第二步redis-cli -n 2 get celery-task-meta-task_id查任务结果确认是{status: FAILURE, result: ...}- ✅ 第三步检查spider_fund.py里_request_with_retry()的重试次数线上我们设为3次每次间隔2秒总超时10秒。故障4用户调用/fund/refresh接口超时但Worker日志显示任务已完成- ✅ 第一步确认前端调用的是FastAPI接口不是直接调Celery。/fund/refresh路由里应该有task update_fund_nav_daily.delay()然后return {task_id: task.id}- ✅ 第二步检查celery_config.py里CELERY_TASK_RESULT_EXPIRES None否则AsyncResult.get()会超时- ✅ 第三步redis-cli -n 2 keys *task_id*确认结果是否真的存进去了。故障5份额数据同步后前端显示“0份”- ✅ 第一步mysql -u root -p -e SELECT * FROM shares_record WHERE fund_code000001 ORDER BY date DESC LIMIT 5;确认DB里有数据- ✅ 第二步redis-cli -n 3 keys user_shares_summary:*看缓存是否存在如果存在redis-cli -n 3 del user_shares_summary:123强制刷新- ✅ 第三步检查shares_mng.py里sync_shares_data_for_fund()的db.commit()是否被执行加日志确认。5. 实操心得与避坑指南那些文档里不会写的细节我在客户现场部署这个增强包时记下了七条血泪经验现在毫无保留分享给你第一条永远不要在Celery任务里用print()调试。Worker进程是守护进程print输出不会到console而是进/dev/null。正确做法是用logger.info(xxx)并在celery_config.py里配置loggingCELERY_WORKER_LOG_FORMAT [%(asctime)s: %(levelname)s/%(processName)s] %(message)s CELERY_WORKER_TASK_LOG_FORMAT [%(asctime)s: %(levelname)s/%(processName)s][%(task_name)s(%(task_id)s)] %(message)s这样journalctl -u celery-worker就能看到带任务ID的结构化日志。第二条爬虫的User-Agent轮询必须带随机sleep。我们最初只轮换UA结果天天基金网封了我们IP。加上time.sleep(random.uniform(1, 3))后再没被封过。道理很简单真人浏览器访问有随机间隔机器人没有。第三条get_data_by_cache.py的缓存键必须包含业务上下文。比如get_fund_nav(code, sourceeastmoney)和get_fund_nav(code, sourcemorningstar)必须用不同key否则数据会串。我们约定key格式为f{source}:{code}:nav。第四条数据库事务的db.rollback()必须在except块里且不能写在finally里。因为db.commit()成功后db.rollback()会报错。正确的模板是上面shares_mng.py里展示的“try-commit-except-rollback”三段式。第五条CentOS的SELinux必须关掉。sudo setenforce 0否则systemd启动的Worker进程无法访问Redis端口报错Permission denied。这不是Bug是SELinux策略限制关掉最省事。第六条celery_config.py里的BROKER_URL和CELERY_RESULT_BACKEND必须用不同Redis DB。我们吃过亏Broker和Result共用DB1结果Beat往DB1发任务Worker从DB1取任务但Result也存DB1导致key冲突任务状态混乱。物理隔离是最稳妥的。第七条所有定时任务的schedule必须用crontab字符串而不是timedelta。timedelta(hours1)在夏令时切换日会出问题0 * * * *是POSIX标准所有系统都认。最后分享一个小技巧我们给每个Celery任务加了监控埋点。在celery_task.py里定义一个通用装饰器def monitor_task(func): functools.wraps(func) def wrapper(*args, **kwargs): start_time time.time() result func(*args, **kwargs) duration time.time() - start_time # 上报到Prometheus或写入日志 logger.info(fTask {func.__name__} took {duration:.2f}s) return result return wrapper celery_app.task monitor_task def update_fund_nav_daily(): ...这样不用改业务逻辑就能知道哪个任务拖慢了整个调度系统。上线后我们发现sync_shares_data_hourly平均耗时12秒果断把它拆成按基金代码分片执行性能提升3倍。这个增强包不是银弹但它把FastAPI后端从“能用”推进到“敢用”的临界点。当你不再需要半夜爬起来手动跑脚本当你的投票系统在基金数据接口抖动时依然稳如泰山你就知道这些配置、这些爬虫、这些缓存策略每一行代码都值回票价。本文还有配套的精品资源点击获取简介基于爱投票FastAPI主项目构建的生产就绪型扩展包重点强化后台异步任务与外部金融数据接入能力。内置Celery分布式任务框架支持定时执行Beat和异步处理Worker已预置配置文件celery_config.py、任务注册入口celery_task.py并提供CentOS下独立部署Worker与Beat服务的完整操作指南涵盖环境依赖安装、服务启停、日志定位及典型故障处理。业务层面新增fund_mng.py和shares_mng.py两大模块分别实现基金基础信息维护与基金份额数据管理配套spider_fund.py和spider_shares.py两个定向爬虫脚本可按需抓取公开基金净值、份额变动等结构化数据结合get_data_by_cache.py提供缓存优先的数据读取机制降低重复请求开销提升接口响应效率。原有用户、角色、权限、菜单、部门、投票等核心管理模块user_mng、role_mng、auth_mng、menu_mng、department_mng、vote_mng保持兼容不变所有新增功能均通过标准FastAPI路由与数据库模型model.py、db_base.py集成不改动原系统架构。注意本包不含基础框架代码必须与《爱投票系统 - FastAPI后端项目一》配合使用方可运行。本文还有配套的精品资源点击获取