schedule库本身不解决幂等性，因其仅负责定时入队和调用函数，不记录状态、无锁机制、不支持外部协调；需自行通过数据库唯一约束、Redis分布式锁等方式实现。
为什么 schedule 库本身不解决幂等性
因为 schedule 只是把函数塞进队列、按时调用，它不管这个函数执行了几次、有没有成功、会不会重复写数据库。你写个 send_email(user_id)，它就真的一次又一次调用——哪怕上次还没发完，或者网络超时导致发了两遍。
常见错误现象：schedule.every(10).minutes.do(send_notification) 在进程重启后没做去重，结果同一通知发了三轮；或者服务部署多实例，每个实例都跑一套 schedule，通知直接翻倍。
- 它不记录执行状态，也不检查上一次是否完成
- 没有内置锁、没有任务 ID、不支持外部存储协调
- 所有“只运行一次”的逻辑，必须你自己加
用数据库唯一约束 + INSERT ... ON CONFLICT 挡住重复
这是最轻量、最可控的方式：把每次要执行的任务抽象成一条带时间戳和业务键的记录，先尝试插入，只在插入成功时才真正干活。
使用场景：发短信、更新用户积分、生成日账单这类不能重复的核心操作。
立即学习“Python免费学习笔记（深入）”；
示例（PostgreSQL）：
INSERT INTO task_run_log (task_name, run_at, status)
VALUES ('daily_report', '2024-06-15 02:00:00', 'pending')
ON CONFLICT (task_name, DATE(run_at)) DO NOTHING;
如果这条 SQL 返回影响行数为 0，说明当天这个任务已存在，跳过执行；为 1，则继续走后续逻辑。
- 关键参数是
task_name和日期粒度的组合，不是单纯用 UUID - MySQL 用户用
INSERT IGNORE或REPLACE INTO，但注意后者会触发 DELETE+INSERT，可能影响自增 ID 或触发器 - 别依赖 Python 层的
if not executed_today:判断——多进程下必然竞争
APScheduler 的 coalesce=True 不等于幂等
它只保证“漏掉的调度只执行一次”，比如服务停了 3 小时，原本该跑 18 次的任务，恢复后只跑 1 次。但它不防并发、不防重入、不防多实例。
容易踩的坑：
-
coalesce=True对IntervalTrigger(minutes=1)有效，但对CronTrigger(hour='2')基本无效——cron 类型默认就只按计划点触发一次 - 如果你用
BackgroundScheduler+ 多个 worker 进程，每个进程都起一个 APScheduler，coalesce在各自进程内生效，全局照样重复 - 它不阻止函数内部重复写 DB 或发消息，只是少调用几次函数而已
用 Redis 分布式锁做临界区控制
适合需要严格串行、且能接受短暂延迟的场景，比如库存扣减、支付对账。
核心逻辑：执行前先 SET key value EX 300 NX，拿到锁才继续；结束后 DEL（注意用 Lua 脚本防误删）。
性能影响明显：每次任务多一次 Redis 往返；锁过期时间必须大于任务最大耗时，否则可能被其他实例续上并行执行。
- 别用
redis-py的lock.acquire()默认行为——它会阻塞等待，而定时任务不该卡住整个调度线程 - 推荐用
try_lock = redis.set(key, 'running', ex=300, nx=True)，返回True再干活，否则直接 return - Redis 故障时锁失效，得配合数据库唯一约束兜底，不能只靠 Redis
复杂点在于锁生命周期和任务实际耗时的匹配，还有跨实例间时钟漂移——这些细节一旦忽略，表面看没问题，压测或上线后才暴露重复。
