首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >Python定时任务踩坑记录,schedule和cron到底用哪个好

Python定时任务踩坑记录,schedule和cron到底用哪个好

作者头像
用户11081884
发布2026-07-20 20:35:50
发布2026-07-20 20:35:50
320
举报

你是不是有这样的场景:半夜两点被一条报警短信炸醒了。

爬起来一看,线上数据采集脚本挂了。原因很离谱——服务重启之后,我用 schedule 库写的定时任务没跟着自动拉起来,整整漏了6个小时的数据。

这事儿说白了就是自己挖的坑。趁着记忆还热乎,把这两年用Python做定时任务踩过的坑都捋一遍,也顺便聊聊 schedule 和 cron 这俩老冤家,到底该怎么选。


先说schedule,确实香

刚接触定时任务那会儿,我一眼就相中了 schedule。为啥?因为它真的太简单了:

代码语言:javascript
复制
importschedule
importtime

defsync_data():
    print("开始同步数据...")
    # 你的业务逻辑

schedule.every(10).minutes.do(sync_data)
schedule.every().day.at("02:00").do(sync_data)

whileTrue:
    schedule.run_pending()
    time.sleep(1)

看到没?几行核心代码,一个定时任务就跑起来了。不用学什么cron表达式,不用碰Linux系统配置,pip install schedule 装完就能用。

那段时间我跟人安利schedule都是这么说的:“兄弟,别搞那些花里胡哨的,schedule一把梭就完了。”

直到被现实反复教育。


schedule的坑,我是真踩了不少

进程一挂,任务全没

这个最致命。schedule的任务列表是存在内存里的,进程一死,所有调度规则灰飞烟灭。

你可能想,写个 systemd 或者 supervisor 把进程拉起来不就行了?太天真了。进程重启之后,schedule不会记得上次任务执行到哪了,也不会帮你把漏掉的任务补回来。

我就遇到过一次,周五晚上服务OOM被系统杀了,周一早上才有人发现,中间两天的数据全是空的。老板问我怎么回事,我总不能说“Python的定时任务太脆弱了”吧……

阻塞起来要命

schedule默认是单线程串行执行的。假设你有两个任务,A每隔5分钟跑一次,B每小时跑一次。A里面有个慢查询,某次跑了8分钟,那B就得等着,活生生被拖延。

代码语言:javascript
复制
importschedule
importtime

defslow_task():
    print("慢任务开始...")
    time.sleep(500)  # 模拟一个耗时操作
    print("慢任务结束")

defquick_task():
    print("快任务执行了!")

schedule.every(5).minutes.do(slow_task)
schedule.every(10).minutes.do(quick_task)

whileTrue:
    schedule.run_pending()
    time.sleep(1)

跑起来你会发现 quick_task 经常迟到,因为它得等 slow_task 跑完才能轮到它。

官方文档倒是说了可以用多线程来绕:

代码语言:javascript
复制
importthreading

defrun_threaded(job_func):
    job_thread = threading.Thread(target=job_func)
    job_thread.start()

schedule.every(10).minutes.do(run_threaded, slow_task)

但你不觉得这已经开始变味了吗?本来图它简单,现在得自己管线程……那我还不如直接用更专业的工具呢。

啥都没有

schedule本质上就是一个“到点了就调函数”的小工具。它不管任务执没执行成功,不管日志写到哪,也不管出了异常要不要重试。你在生产环境用,出了问题全靠自己的 printtry-except 去排查。

这就好比你开着一辆没有仪表盘的车上高速——跑是能跑,但你永远不知道油还剩多少。


转投cron阵营

被schedule坑了几次之后,我把目光转向了cron。

这里说的“cron”不是某个Python库,而是Linux系统自带的 crontab 定时任务。这玩意儿从1975年就有了,比你我都老,真正的久经考验。

用法也很直白:

代码语言:javascript
复制
# 编辑当前用户的crontab
crontab -e

# 每10分钟执行一次Python脚本
*/10 * * * * /usr/bin/python3 /home/user/scripts/sync_data.py

# 每天凌晨2点执行
02 * * * /usr/bin/python3 /home/user/scripts/daily_report.py

写完保存就生效了,不用写 while True 循环,不用操心进程挂不挂,系统级的 crond 守护进程帮你管着呢。

当时我就想,这多好,稳如老狗。

然后我又被教育了。


cron的坑也不少,只是坑法不一样

环境变量——永远的经典

cron踩坑界的扛把子,没有之一。

你在终端里手动跑得好好的脚本,丢到crontab里就是不work。十有八九是环境变量的锅。因为cron执行命令时用的是一个极简环境,PATH只有 /usr/bin:/bin,你装的那些pip包、conda环境、自定义变量,它一概不认。

这个问题我至少踩过三次,每次都是“不应该啊”→ 排查半小时 → “又是环境变量”。

解决方案倒是不复杂:

代码语言:javascript
复制
# 方法1:在crontab头部声明PATH
PATH=/usr/local/bin:/usr/bin:/bin:/home/user/.local/bin
*/10 * * * * python3 /home/user/scripts/sync_data.py

# 方法2:用绝对路径(我最推荐这个)
*/10 * * * * /home/user/venv/bin/python /home/user/scripts/sync_data.py

# 方法3:source一下环境
*/10 * * * * source /home/user/.bashrc && python3 /home/user/scripts/sync_data.py

方法2最省心,也最不容易出幺蛾子。别问我是怎么知道的。

工作目录跟你以为的不一样

cron执行脚本时,工作目录默认是用户的home目录,不是脚本所在的目录。

如果你脚本里用了相对路径读文件:

代码语言:javascript
复制
# sync_data.py
withopen("config.json") asf:  # cron环境下这个路径是错的
    config = json.load(f)

终端里跑没问题,一放到cron里就报 FileNotFoundError,你说气不气。

解决办法很简单,脚本开头加一行:

代码语言:javascript
复制
importos
os.chdir(os.path.dirname(os.path.abspath(__file__)))

或者直接在crontab里先cd过去:

代码语言:javascript
复制
*/10 * * * * cd /home/user/scripts && python3 sync_data.py

日志去哪了?

cron默认会把输出发到系统邮件里,对,就是那个没人看的 /var/mail/ 目录。你要是没做重定向,出了bug都不知道去哪找。

所以请一定记住加日志重定向,这是铁律:

代码语言:javascript
复制
*/10 * * * * python3 /home/user/scripts/sync_data.py >> /home/user/logs/sync.log 2>&1

2>&1 是把错误输出也写到同一个文件里。别嫌麻烦,等你半夜排查问题的时候,你会感谢当时的自己。

时区问题,玄学中的玄学

cron用的时区取决于系统设置,而你服务器的时区可能跟你以为的不一样。

我碰过一次,服务器是UTC,我以为配的是北京时间凌晨2点,结果实际上是北京时间上午10点执行的。数据分析那边一看报表数据对不上,又是一通排查。这种问题特别难定位,因为你压根不会第一时间怀疑时区。

代码语言:javascript
复制
# 先检查系统时区
timedatectl

# 在crontab里声明时区(部分系统支持)
CRON_TZ=Asia/Shanghai
02 * * * python3 /home/user/scripts/daily_report.py

到底怎么选?

说了这么多,我自己的原则很简单——

schedule只用在临时脚本上。本地开发、数据验证、写个一次性脚本跑跑测试。比如你临时写个脚本每隔10分钟去某个API拉一下数据做调试,schedule绝对是最快的方案,没得说。但用完就扔,别惦记着让它上生产。

cron才是要上线的东西。线上服务、生产环境、任何你不想半夜被叫起来修的任务。cron虽然配置麻烦一点,但它稳定可靠有系统级别的保障,是真正的“设了就忘”。

如果你还需要更复杂的功能,比如任务依赖、分布式调度、Web管理界面之类的,可以看看 APScheduler 或者 Celery Beat,不过那就是另一个故事了,以后有机会再聊。


一张表看明白

维度

schedule

cron (crontab)

上手难度

极低,5分钟搞定

中等,得学cron语法

进程依赖

依赖Python进程存活

系统级守护进程,独立管理

持久化

无,重启就丢

有,写入系统配置

并发执行

默认串行

天然并行,每个任务独立进程

日志监控

无,需自己实现

可配合系统日志,支持重定向

跨平台

全平台

仅Linux/macOS

异常恢复

系统自动拉起crond

适用场景

开发调试、临时脚本,别心存侥幸

生产环境、长期运行任务


说两句

我现在线上全用cron,schedule只在本地的临时脚本里出现。

之前也不是没想过在服务器上继续用schedule,套了个 supervisor 做进程管理,再加上日志和报警,折腾完发现这一套搞下来,比直接写crontab还麻烦。何必呢。

cron虽然老派,但架不住人家稳啊。别总想着整花活,能跑的代码才是好代码。

你们线上定时任务用的什么方案?有用Celery Beat或者APScheduler的来评论区说说体验,我最近也在调研。

“无他,惟手熟尔”!有需要的用起来!

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2026-06-22,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 Nicholas与Pypi 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 先说schedule,确实香
  • schedule的坑,我是真踩了不少
  • 转投cron阵营
  • cron的坑也不少,只是坑法不一样
  • 到底怎么选?
  • 一张表看明白
  • 说两句
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档