cron包无法满足生产级可靠性，因其是单机内存调度器，无状态持久化、无分布式锁、无幂等保障，导致任务丢失、重复执行或中断无补偿。
为什么 cron 包无法满足生产级任务可靠性
Go 标准库 cron（如 github.com/robfig/cron）本质是单机内存调度器，进程崩溃、重启、扩缩容都会导致任务丢失或重复执行。它不记录任务状态，也不提供幂等性保障，一旦节点宕机，job.Run() 就永远消失了。
真实场景中，你遇到的典型问题包括：
- 服务滚动更新时，正在执行的定时任务被 SIGTERM 强制中断，且无补偿机制
- 两个实例同时拉取到同一个待执行任务（缺乏分布式锁）
- 任务执行失败后未持久化失败状态，下次调度又重试，但上游已处理成功 → 重复扣款
用数据库 + 状态机实现任务一致性
核心思路：把“任务定义”和“任务执行状态”拆开，全部落库。每次调度不是直接调函数，而是先 UPDATE ... SET status = 'running' WHERE id = ? AND status = 'pending'，仅当影响行数为 1 才真正执行。
推荐表结构（以 PostgreSQL 为例）：
立即学习“go语言免费学习笔记（深入）”；
CREATE TABLE scheduled_tasks ( id SERIAL PRIMARY KEY, job_name TEXT NOT NULL, payload JSONB, status TEXT NOT NULL DEFAULT 'pending', -- pending / running / succeeded / failed scheduled_at TIMESTAMPTZ NOT NULL, started_at TIMESTAMPTZ, finished_at TIMESTAMPTZ, error TEXT, max_retries INT DEFAULT 3, retry_count INT DEFAULT 0, created_at TIMESTAMPTZ DEFAULT NOW() ); CREATE INDEX idx_tasks_due ON scheduled_tasks (scheduled_at) WHERE status = 'pending';
关键操作逻辑：
- 调度器每秒查一次
SELECT * FROM scheduled_tasks WHERE status = 'pending' AND scheduled_at - 对每条结果尝试原子更新：
UPDATE scheduled_tasks SET status = 'running', started_at = NOW() WHERE id = $1 AND status = 'pending' - 只有
RowsAffected == 1才进入业务逻辑；否则跳过（说明已被其他 worker 抢占） - 执行完成后，用事务更新最终状态 —— 成功则
succeeded，失败则根据retry_count 决定设为pending（并更新scheduled_at为退避时间）或failed
避免重复消费的关键：SELECT FOR UPDATE 不够用
很多人第一反应是用 SELECT ... FOR UPDATE 加行锁，但这在高并发下仍可能出问题：事务开启、查出记录、业务执行耗时长、提交前锁已释放（取决于隔离级别和驱动行为），别人仍可能读到旧状态。
真正可靠的抢占必须依赖「条件更新」+「返回值校验」，即上面提到的 UPDATE ... WHERE status = 'pending'。这是唯一能跨进程达成共识的操作。
注意几个易错点：
- 不要用
SELECT ... FOR UPDATE SKIP LOCKED后再UPDATE—— 中间存在竞态窗口 - 所有状态变更必须走同一张表、同一字段、同一条件，不能一部分用
status，一部分用is_processed - 如果使用 MySQL，确保事务隔离级别为
READ COMMITTED或更高，否则可能读到脏数据影响判断
如何安全地停止一个正在运行的任务 Worker
直接 kill 进程会导致 running 状态卡死，后续永远无人处理。正确做法是让 Worker 主动退出，并把未完成任务回滚为可重试状态。
实现方式：
- Worker 启动时注册
os.Interrupt和syscall.SIGTERM信号处理器 - 收到信号后，设置全局
shutdownFlag，不再拉取新任务 - 等待当前正在执行的任务自然结束（或加超时 context 控制）
- 最后执行一次清理：将本 worker 标记为
running但超过started_at + 5 minutes的任务批量设为pending（防止假死）
示例清理语句：
UPDATE scheduled_tasks SET status = 'pending', retry_count = retry_count + 1, scheduled_at = NOW() + INTERVAL '30 seconds' WHERE status = 'running' AND started_at < NOW() - INTERVAL '5 minutes' AND retry_count < max_retries;
这个兜底逻辑必须独立于 Worker 生命周期存在，建议由另一个轻量 health-check goroutine 每分钟执行一次。
