Golang 实现基于内存的任务调度系统

说实话，直接用 time.Ticker 或者裸 go f() 去写内存任务调度，十有八九线上会出问题——不是功能实现不了，而是 panic 丢任务、执行堆积、无法取消、时钟漂移漏触发，这四个坑几乎必踩。

别把 time.Ticker 当调度器用

time.Ticker 本质上就是个信号发生器，它只管按时间发信号，从不关心任务是否执行完毕。一旦某个任务耗时超过时间间隔，问题就来了：

• 任务执行 8 秒，但定时器设的是 5 秒，第 5 秒和第 10 秒各触发一次，结果两个实例同时跑起来
• 任务里如果 panic 没 recover，整个 ticker 的 goroutine 会静默退出，后续所有任务全部丢失
• 系统 NTP 校准时，类似 time.Now().Hour() == 9 这种判断可能跳过，也可能重复执行一次
• 没有任务 ID，想按名称停掉某个任务？做不到。临时暂停或动态调整间隔？也做不到

如果非要用，必须加状态锁：sync.Mutex 或 atomic.Bool 确保单次执行期间不响应新 tick；每次启动前确认 ticker.Stop()，否则 goroutine 泄漏只是时间问题。

用 container/heap 实现带优先级的内存队列

如果不想引入外部依赖，又想要可控性，标准库的 container/heap 就是最稳妥的选择。自己手工排序 slice 或者引入第三方库，反而增加了不确定性。

• 任务结构体必须包含 Priority int（数值越小优先级越高）、NextRunAt time.Time、ID string 这三个字段
• Less 方法先比较 Priority，再比较 NextRunAt，避免高优先级任务被低优先级任务饿死
• 主循环用单个 *time.Timer 指向堆顶任务：每次变更后先 timer.Stop() 再 timer.Reset()，否则会 panic 或泄漏
• 判断超时时不要用 time.Now().UnixNano()，机器间时钟偏差会导致误判，改用单调递增序列号或本地逻辑时钟更可靠

执行器必须带 worker pool + context + recover

任务不能裸起 goroutine，否则 panic 杀进程、无并发控制、无法统一限流，这些坑一个都不能踩。

• 固定数量 worker（比如 4–8 个）从 channel 拿任务，channel 缓冲建议设为 100，防止生产者阻塞
• 每个 worker 必须包 defer func() { recover() }()，捕获 handler panic 并转为可重试错误
• 任务函数签名强制为 func(context.Context, map[string]interface{}) error，确保能传入取消信号与参数
• 执行过程中必须定期检查 ctx.Err() != nil，及时退出；禁止在 Run() 里起长期 goroutine 而不绑定 ctx，否则节点重启后会留下幽灵进程

任务注册要零侵入，但必须带幂等控制

别让用户去实现 interface 或者继承 base struct。靠反射识别函数签名就能注册，但幂等性必须由调度器兜底。

• 任何函数只要满足 func(context.Context, map[string]interface{}) error 就能注册，调度器自动提取函数名作为 jobType
• 每个任务带唯一 jobID 和 execID（形如 "job-abc123-exec-456"），worker 执行前查本地 execMap map[string]bool，命中则返回 ALREADY_EXECUTED
• 网络抖动会导致 leader 重复下发同一个 jobID，仅靠 jobID 不够，必须靠 execID 区分不同执行轮次
• 禁止在任务函数里做全局状态修改（比如直接改 package var），所有状态应通过参数传入或由上下文管理

最容易被忽略的，其实是三个点：执行上下文（context.Context）、幂等边界（execID 而非 jobID）、以及 timer 生命周期管理（Stop() + Reset() 必须成对出现）。这三条任意一条没对齐，就不是“基于内存的稳定调度”，充其量算个玩具 demo。