etcd凭借Lease+CompareAndSwap天然支持分布式锁与Leader选举，结合Watch机制、强一致性和Raft共识，可构建轻量、可控、低延迟、无外部依赖的自研分布式任务队列，适用于细粒度任务、定制重试及纯Go技术栈场景。
为什么不用现成的 Redis + Celery 或 Kafka？
Go 生态里直接拿来即用的分布式任务队列确实不少，但如果你要的是「轻量、可控、低延迟、无外部依赖绑架」，硬套 Celery（Python）或 Kafka（JVM 重）反而会拖慢整个 Go 服务链路。真正需要自研的典型场景是：任务粒度细（毫秒级执行）、失败重试策略需定制、上下游全是 Go 且已用 etcd/raft 做协调——这时候 go-workers 或 asynq 是更贴身的选择，但它们仍依赖 Redis。真想彻底去中心化，就得自己搭骨架。
用 etcd 实现任务注册与 Leader 选举
etcd 不只是配置中心，它的 Lease + CompareAndSwap 能天然支撑分布式锁和 leader 选举，比轮询数据库或自建心跳更可靠。
- 任务生产者往
/tasks/queue下写入 JSON 任务项，带id、payload、retry_count、next_run_at - 所有 worker 启动时用
etcd.Client.Grant申请一个 10s 的 lease，并在/workers/leader路径下用txn.Compare竞争写入自身 ID + lease ID - 只有成功写入的 worker 成为 leader，负责从
/tasks/queue拉取待执行任务（按next_run_at排序），再分发给其他 worker（通过 channel 或直接 HTTP push）
注意：etcd 的 watch 机制不保证顺序，所以 leader 拉取任务必须用 Get + Sort，不能只靠 watch event 做触发。
worker 并发模型怎么设才不爆内存？
别一上来就 go handleTask(task) 起几百个 goroutine。真实压测中，10k 任务涌入时，未加控的 goroutine 泄漏会让 RSS 冲到 2GB+。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 用固定 size 的
sync.Pool复用任务结构体，避免高频 GC - 执行层必须套
semaphore：比如用golang.org/x/sync/semaphore控制并发数，设为 CPU 核数 × 2（非 I/O 密集型任务） - 每个 task 执行前检查 context 是否超时：
select { case <-ctx.Done(): return ctx.Err() }，否则卡住的 goroutine 无法回收
示例节选：
sem := semaphore.NewWeighted(int64(runtime.NumCPU()*2))
// ...
if err := sem.Acquire(ctx, 1); err != nil {
return
}
defer sem.Release(1)
handleTask(ctx, task)
任务失败后怎么重试又不重复执行？
幂等性不是靠“加锁”实现的，而是靠状态机 + 唯一标识。每个任务生成时必须带 id（如 uuid.NewSHA1(uuid.Nil, []byte(fmt.Sprintf("%s:%d", task.Type, time.Now().UnixNano())))），并在执行前先写入 /tasks/executed/{id}（带 lease），成功后再删。
- 如果 worker A 写入
/tasks/executed/abc123后 crash，lease 过期自动清理，其他 worker 发现该路径不存在，才允许接手 - 重试逻辑由 leader 统一调度：扫描
/tasks/queue中next_run_at < now且retry_count < 3的任务，更新其next_run_at = now + backoff（如 1s → 2s → 4s）
最常被忽略的一点：etcd 的 revision 是全局递增但不连续的，别用它做分页拉取；要用 Range 配合 Limit + SortOrder，否则漏任务。
