APScheduler不适合百万级定时任务，因其本质是单进程内存调度器，依赖主线程轮询扫描全部job，无索引、无分片、不可水平扩展，任务超10万即严重卡顿甚至崩溃。
为什么 APScheduler 不适合百万级定时任务
APScheduler 本质是单进程内存调度器，所有任务都注册在 jobstore（默认是 MemoryJobStore）里，靠主线程轮询 get_due_jobs() 触发。当任务量上百万，哪怕只是每分钟检查一次，len(jobs) 和逐个比对 next_run_time 的开销就直接卡死——这不是调优能解决的架构瓶颈。
常见错误现象：RuntimeWarning: Execution of job "xxx" skipped: maximum number of running instances reached 或 CPU 持续 100%、调度延迟秒级起步、进程 OOM 崩溃。
- 任务数 > 10k 就明显变慢；> 100k 时基本不可用
- 所有 job 时间戳都存在 Python 对象里，没索引、没分区、没持久化压缩
- 不支持横向扩展：加进程或机器无法分摊 job 存储与扫描压力
替代方案必须满足的三个硬条件
百万级定时任务不是“让 APScheduler 更快”，而是换掉调度模型。真正可行的路径得同时满足：
-
时间维度可索引：不能遍历全部 job 查“谁该执行了”，要能按
next_run_time范围快速定位（如数据库 B-tree 索引、Redis ZSET 跳表） - 执行单元可水平伸缩：worker 进程/容器只拉取自己负责的时间片（例如按秒哈希分片），不共享 job 全集
-
失败可追溯+幂等重试：单次执行失败不能丢任务，需记录状态（
pending/running/success），且 job handler 必须支持幂等
典型组合：PostgreSQL（带 next_run_at 索引 + FOR UPDATE SKIP LOCKED 分片拉取） + 多 worker 进程 + Redis 去重锁。
立即学习“Python免费学习笔记（深入）”；
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
用 PostgreSQL + pg_cron 做底层调度骨架
pg_cron 是 PostgreSQL 扩展，把调度逻辑下沉到数据库层，避免 Python 进程扛全量 job 扫描。它本身不处理百万任务，但可作为“粗粒度触发器”——比如每秒触发一次 Python worker 执行“拉取本秒到期的 500 个 job”。
建表示例：
CREATE TABLE scheduled_job (
id SERIAL PRIMARY KEY,
task_name VARCHAR(128) NOT NULL,
payload JSONB,
next_run_at TIMESTAMPTZ NOT NULL,
status VARCHAR(16) DEFAULT 'pending',
max_retries INT DEFAULT 3,
retry_count INT DEFAULT 0
);
CREATE INDEX idx_next_run_at ON scheduled_job (next_run_at) WHERE status = 'pending';
关键点：
- WHERE 条件索引大幅减少扫描行数，
next_run_at精确到秒即可（微秒精度反而拖慢索引） - worker 执行
UPDATE ... RETURNING *加Skip Locked实现并发安全拉取，避免重复执行 - 不要用
SELECT FOR UPDATE后再UPDATE—— 中间可能被其他 worker 抢走，直接原子更新更稳
Python worker 如何避免成为新瓶颈
worker 本身也要防止单点压垮：不是“一个进程跑所有 job”，而是每个 worker 只处理固定时间片（如 next_run_at 秒数 % 100 == self.shard_id）。
- 用
asyncio+aiohttp或httpx.AsyncClient并发调用下游，别用 requests 阻塞式 - 批量拉取：每次
SELECT ... LIMIT 500，而不是 1 个 1 个查 - 失败 job 写回时更新
next_run_at = NOW() + INTERVAL '2^retry_count SECOND'，实现退避重试 - 务必加 Redis 锁（
redis.set(task_id, '1', ex=60, nx=True)）防止同一任务被多个 worker 同时执行
高精度 ≠ 高频：真正需要毫秒级触发的任务极少，绝大多数场景“秒级触发 + 任务内自控毫秒逻辑”更实际。强行在调度层做毫秒对齐，只会把问题从 Python 转移到数据库 WAL 日志和锁竞争上。
