Redis分布式锁易误判超时是因为SET成功后业务执行超时导致锁提前过期，需用唯一value校验+原子续期；ZK锁需监听前序节点防羊群效应，session timeout须大于业务超时；解锁必须用Lua脚本而非DEL。
Redis 分布式锁为什么容易误判超时？
Redis 锁最常出问题的不是加锁失败，而是 SET key value EX seconds NX 成功了，但业务逻辑执行超时，锁提前过期，另一个进程趁机抢入——这不是锁没生效，是「租约」和「执行时间」没对齐。
- 用
redis.SetNX+redis.Expire两步走？原子性没了，中间可能崩溃，导致死锁 - 必须用单条命令：Go 客户端（如
github.com/go-redis/redis/v9）推荐SetNX(ctx, key, value, ttl)，value必须是唯一标识（比如 UUID），后续解锁靠它校验所有权 - 别依赖客户端本地时间算过期；Redis 服务端时间更可靠，所以
EX参数直接传time.Second * 30，别在代码里算毫秒再减去网络延迟 - 实际运行中，如果业务耗时波动大（比如 DB 查询慢），建议把 TTL 设为预估最大耗时的 2–3 倍，并配合后台续期协程（watchdog）——但续期本身也要防并发，得用 Lua 脚本保证原子性
Zookeeper 的 createEphemeralSequential 锁怎么避免羊群效应？
ZK 锁本质是利用临时顺序节点 + Watcher，但默认实现下，每次释放锁，所有等待者都会被唤醒，大量节点争抢，就是羊群效应——QPS 上去后 ZK 集群压力陡增，延迟飙升。
- 正确做法是只监听「前一个节点」：创建
/lock/xxx_000000001后，getChildren(/lock, false)拿到全量子节点，排序，找到自己前一个（比如xxx_000000000），然后exists(/lock/xxx_000000000, watcher=true) - Go 用
github.com/samuel/go-zookeeper/zk时，exists()的第二个参数设为true才会注册 Watcher；漏掉就变成轮询，失去 ZK 的事件驱动优势 - ZK session timeout 是关键参数：
time.Minute * 3是常见值，太短容易误踢（GC 或网络抖动），太长则故障恢复慢；和业务超时必须错开，比如锁业务逻辑设 10s，session timeout 至少 30s - 注意 ZK 的
ephemeral节点只在 session 存活时有效，不是连接不断就行——断连重连后若没及时 re-create，锁就丢了
Go 里选 Redis 还是 Zookeeper？看这三点就够了
不比“谁更好”，只看你的服务部署环境、运维能力和一致性要求。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 如果你的 infra 已有稳定 Redis 集群，且能接受「最多一次」语义（即锁失效可能导致重复执行，但可幂等兜底），选 Redis：轻量、快、client 成熟，
Redlock在多实例场景下反而增加复杂度，普通单节点 Redis + 正确的 value 校验 + 续期就够用 - 如果你系统已重度依赖 ZK（比如用它做服务发现、配置中心），且业务对强一致性敏感（如金融类资金扣减），ZK 更合适：它的顺序性和 watch 机制天然支持严格 FIFO，不会因网络分区出现双主
- 别忽略 Go runtime 特性：ZK client 默认启多个 goroutine 处理心跳和事件，若你服务本身 goroutine 数受限（比如 serverless 环境），Redis client 的资源占用更可控；用
redis.UniversalClient时记得调SetPoolSize()，别让连接池爆炸
解锁时用 DEL 还是 Lua 脚本？
直接 DEL key 是最常见错误——它不检查 value，任何进程都能删别人的锁，等于没锁。
立即学习“go语言免费学习笔记（深入）”；
- 必须用 Lua：保证「判断 value == own_value」和「DEL」原子执行。Go 示例：
script := redis.NewScript(`if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end`)然后script.Run(ctx, rdb, []string{key}, value).Val() - Redis 6.2+ 支持
UNLINK，但解锁不用它——DEL足够快，UNLINK是为大 key 异步删除设计的，这里反而多一层调度开销 - ZK 解锁简单得多：直接
delete()临时节点，ZK 自动保障只有创建者能删（ACL 可配，但默认就是 owner-only）；不需要 value 校验逻辑 - Go 调 ZK
delete()时传错 version 会报zk.ErrNoNode或zk.ErrBadVersion，别当成成功——要检查 error 类型，不是 nil 就得重试或告警
实际落地最难的不是选哪种，是把锁的生命周期和业务流程对齐：超时设置、续期时机、异常清理、监控埋点——这些地方一松动，分布式锁就从保险丝变成定时炸弹。
