Go语言无原生分布式调度能力，需用Asynq（Redis轻量）或Temporal（PostgreSQL重型）等专用库实现跨节点、一致性、防重执行；二者均要求任务幂等，且依赖存储可靠性配置。
Go 语言本身不提供开箱即用的分布式任务调度能力，time.Ticker 和 time.AfterFunc 只能做单机定时；真要跨节点、保一致性、防重复执行，必须引入外部协调机制或专用库。
为什么不能直接用 goroutine + time.Sleep 做分布式调度
这种写法在单机测试时看似可行，但一上生产就出问题：
-
goroutine是进程内资源，节点宕机后所有未执行任务丢失，无持久化、无恢复 - 多个实例同时拉起相同任务，导致重复消费（比如发两次短信、扣两次库存）
- 没有全局时钟对齐，各节点
time.Now()存在毫秒级偏差，影响精确触发 - 无法动态增减 worker 节点，扩缩容等于停服重配
推荐方案：用 Asynq 或 Temporal 接入 Redis / PostgreSQL
这两个是 Go 生态中真正落地的分布式任务调度选择，区别在于抽象层级：
-
Asynq轻量，基于 Redis 实现，适合「延迟队列」和「周期性重试」场景（如订单超时关单、邮件重发），任务状态存在redis的 sorted set + list 中，靠asynq.Server多实例竞争消费 -
Temporal重型，自带服务端（可 Docker 启），支持长时运行、子工作流、信号中断、历史追溯，适合业务逻辑复杂、需审计合规的场景（如支付对账、多步骤审批） - 二者都要求任务函数是幂等的——因为网络分区或 worker crash 可能导致同个
taskID被多次投递
Asynq 最小可行示例：注册、分发、执行三步不能少
漏掉任一环节都会导致任务静默失败或堆积：
立即学习“go语言免费学习笔记（深入）”；
- 定义任务：
asynq.NewTask("send_email", map[string]interface{}{"to": "a@b.com"}) - 注册处理器：
mux.HandleFunc("send_email", sendEmailHandler)，必须在asynq.NewServer启动前完成 - 分发任务时指定
asynq.ProcessIn(5 * time.Minute)或asynq.ScheduleAt(time.Now().Add(10 * time.Second))，否则默认立即入队 - 注意
asynq.RedisClientOpt的DB参数要和业务 Redis DB 隔离，避免 key 冲突或误清空
别忽略存储层的可靠性配置
Redis 或 PostgreSQL 不只是“存一下”，它们直接决定调度是否可靠：
- Redis 必须开启
AOF+fsync everysec，禁用maxmemory-policy volatile-lru，否则内存满时任务被随机丢弃 - PostgreSQL 方案（如用
pgx配合pg_cron）需确保pg_cron扩展已安装，并且crontab条目写的是调用 Go 服务的 HTTP 接口而非直接跑 SQL - 所有任务 payload 序列化建议用
json.Marshal而非gob，避免 Go 版本升级后反序列化失败
分布式调度真正的难点不在 Go 代码怎么写，而在任务语义的界定——这个任务到底算“成功”还是“失败”，由谁判定、何时判定、失败后要不要回滚上游状态。这些逻辑一旦没对齐，加再多节点也只会放大问题。
