Go分布式调度需用Redis实现抢占式锁而非单机cron，核心是SET NX+Lua安全抢锁与释放，配合中心触发+任务队列降低Redis压力，并强制任务幂等与元数据持久化。
go 语言本身没有分布式调度能力，time.ticker 和 github.com/robfig/cron 都只在单进程内生效。要让多个 go 实例协同、不重复执行同一任务，必须靠 redis 做协调——不是“加个锁就完事”，而是得明确谁触发、谁争锁、谁执行、谁清理。
为什么不能直接用 robfig/cron 或 gocron
这两个库默认把调度逻辑全放在内存里：cron.AddFunc 后每个实例都独立跑自己的 timer；gocron.StartBlocking 也不会感知其他节点。10 台机器配同一个 * * * * * 表达式，就是 10 次执行。它们没内置任何跨节点协商机制，WithDistributedLocker 接口只是预留，不带实现。强行套 Redis 锁，还得自己处理抢锁时机、续期、误删、脑裂恢复——等于重造轮子。
用 SET NX + Lua 实现安全抢占式执行
核心是让所有节点在「该执行的那一刻」竞争一个带 TTL 的锁，抢到才干活。这不是装饰性防护，是执行准入门槛。
-
SET task:send_daily_report "host123:45678" EX 300 NX：value 必须是唯一标识（如os.Getenv("HOSTNAME") + ":" + strconv.Itoa(os.Getpid())），EX 设为任务最长耗时的 2–3 倍（比如任务最多跑 90s，TTL 就设 300） - 别用
rdb.SetNX或rdb.SetEX组合——非原子，可能写入 key 但没设过期，导致死锁；老老实实调rdb.Do(ctx, "SET", ...) - 释放锁必须用 Lua 脚本校验 value：
EVAL "if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('DEL', KEYS[1]) else return 0 end" 1 task:send_daily_report host123:45678，否则可能删掉别人刚抢到的锁 - 常见报错：
redis: nil（client 未初始化）、ERR value is not an integer or out of range（EX参数传成字符串或负数）、没设NX导致覆盖旧锁
触发时机设计决定系统是否稳定
很多人让所有节点都挂 robfig/cron，每秒去抢一次锁——Redis 压力大、锁竞争激烈、任务延迟不可控。真正可控的做法是「中心触发 + 分布式执行」：
- 单独起一个轻量调度器（哪怕只是个固定 IP 的 Go 进程），用
robfig/cron定时LPUSH tasks:trigger "report_20260512" - 所有工作节点监听
BRPOP tasks:trigger 5（超时设短点，别卡死），拿到任务 ID 后再抢锁执行 - 如果用
Pub/Sub，注意github.com/go-redis/redis/v9默认断连不自动重连，得监听Subscribe().Err()并手动重建连接 - 避免在 cron 表达式里写高频率项（如
* * * * *），改用低频触发 + 任务队列分发，降低 Redis 冲击
幂等性不是可选项，是前提条件
锁只能防「同时执行」，挡不住「执行中崩溃 → 锁过期 → 另一节点重试」。网络分区、Redis 故障、worker panic 都可能导致同个任务被多次投递。
立即学习“go语言免费学习笔记（深入）”；
- 所有任务函数必须自带幂等判断：比如
send_email先查email_sent:{task_id}是否已存在；generate_report写结果前先SETNX report:{date}:{user_id} "done" - 任务元数据（ID、参数、重试次数）建议存 Redis Hash 或 PostgreSQL，别只放内存里——节点重启就丢状态
- 不要依赖锁来兜底业务逻辑，它只负责「执行权仲裁」；真正的容错靠的是任务自身可重入、状态可追溯、失败可补偿
最易被忽略的一点：锁的 TTL 不是拍脑袋定的。它得大于「从抢锁成功 → 执行完成 → 安全删锁」的整个链路耗时，包括 GC STW、Redis 网络抖动、慢查询。压测时重点看这个窗口是否真能兜住——否则就是看似有锁，实则裸奔。
