多实例定时任务重复执行是设计使然，需用etcd lease抢主+幂等设计防重：查leader、SET NX锁、唯一标识、TTL≥任务耗时3倍，并在业务层加唯一索引、CAS状态机、历史记录校验。
time.Ticker 和 gocron 多实例部署一定会重复执行，这不是 bug，是设计使然。Go 本身不提供分布式语义，所有“定时”原语都只在单进程内有效；真要跨节点协调执行权，必须引入外部协调机制。
别把 gocron.NewScheduler() 当调度中心用
每个 Pod 启动一个 gocron.NewScheduler()，就等于开了 N 个独立闹钟——它们各自维护 timer heap、各自解析 cron 表达式、各自调用 Do()。K8s 扩容到 3 个副本？那 send_daily_report 就会准时被执行 3 次。
常见错误现象：
- 数据库唯一索引报
unique constraint violation - 日志里同一毫秒出现多条
task executed - 短信/邮件/扣款类任务被多次触发
真正防重的关键不是“加锁”，而是“抢执行权”。gocron 的 WithDistributedLocker 接口只是占位符，没实现，文档也没写清这点，容易误判为开箱即用。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 把
gocron当作本地触发器：只用它每分钟调一次tryAcquireAndRun() -
tryAcquireAndRun()内部必须做三件事：查 etcd 确认主节点身份、用SET task:lock:report_20260714 1 NX EX 180抢锁、锁成功才进业务逻辑 - 锁的
EX时间必须 ≥ 任务最长耗时 × 3（如任务通常 20s 完成，设 60s） - 锁 value 写入唯一标识，比如
os.Getenv("HOSTNAME")，出问题能快速定位谁在跑
用 clientv3.Grant + Put + Watch 实现轻量选主
etcd 的 lease 是目前 Go 生态最可控的去中心化协调手段：自动过期、事件驱动、跨节点可见。核心不在“存任务”，而在“谁有资格执行”。
典型流程是所有节点竞争写入 /scheduler/leader 这个 key，只有第一个成功者获得 lease 并持续续租，其余节点 watch 该 key 变更，失效即抢。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
实操要点：
-
clientv3.Grant(ctx, 45)中 TTL 设为任务最长耗时的 2–3 倍（如任务通常 15s 完成，TTL 设 45s） - 抢占必须用
clientv3.OpPut配合clientv3.LeaseID，不能靠GET+SET模拟原子操作——那是竞态温床 - 续租要单独起 goroutine 跑，并监听
lease.KeepAliveChannel关闭（说明 lease 已被 revoke） -
Watch必须加clientv3.WithPrevKV()，否则无法区分“是自己删的”还是“被别人抢走的”
asynq 不是万能胶，但比手撸 etcd 更快落地
如果你的任务场景是「延迟队列」或「失败后自动重试」（如订单超时关单、邮件补发），asynq 是当前 Go 生态中最轻量、最易上手的选择。它基于 Redis，不依赖服务端进程，只要 Redis 可用，就能跑起来。
容易踩的坑：
- 漏注册处理器：
mux.HandleFunc("send_email", sendEmailHandler)必须在asynq.NewServer启动前完成，否则任务静默丢弃 - 分发时不指定时间策略：
asynq.ProcessIn(5 * time.Minute)或asynq.ScheduleAt(...)，否则默认立即入队，失去“延迟”意义 -
asynq.RedisClientOpt的DB参数没和业务 Redis DB 隔离，上线后被FLUSHDB误清空任务队列 - 任务 payload 用
gob序列化——Go 版本升级后反序列化失败，建议统一用json.Marshal
性能影响：Redis 若未开启 AOF + fsync everysec，内存满时可能按 volatile-lru 策略随机丢弃任务；禁用该策略，改用 noeviction 更安全。
所有方案都绕不开幂等性设计
无论你用 etcd lease、Redis 锁，还是 asynq、Temporal，网络分区、worker crash、lease 续租失败都可能导致同一个 task_id 被多次投递。框架只能保证“最多一次调度”，不能保证“恰好一次执行”。
所以业务逻辑层必须自己兜底：
- 数据库操作加唯一索引（如
order_id + event_type联合唯一） - 状态机更新用 CAS：只允许从
pending → running，不允许running → running - 关键操作前先查历史记录，比如发券前查是否已发过同用户同活动
- 避免在
Do()或ProcessTask()里直接写副作用逻辑，先生成幂等 key，再判断是否已处理
最容易被忽略的一点：时间戳不要用 time.Now().Unix() 生成锁 key 或判断执行窗口——各节点时钟偏移可能达几十毫秒，会导致抢锁失败或误判未到执行时间。
