多实例定时任务重复执行是设计使然，需用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 接口只是占位符，没实现，文档也没写清这点，容易误判为开箱即用。

实操建议：

• 把 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 Skill - 高性能缓存管理

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 或判断执行窗口——各节点时钟偏移可能达几十毫秒，会导致抢锁失败或误判未到执行时间。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！