Redis分布式锁必须使用SET key value NX PX milliseconds原子命令实现，NX保证互斥性，PX防止死锁，value须为唯一随机值，解锁和续期均需Lua脚本保障原子性。
Redis SET PX NX 是加锁的唯一安全起点
别信
单独调用能搞定分布式锁——它不带过期时间，一旦客户端崩溃，锁就永远卡住。必须用原子命令
（毫秒级）或
（秒级），让 Redis 服务端一步完成“不存在才设值 + 同时设 TTL”。
的
默认启用
和
，但得确认你连的是 Redis 2.6.12+；老版本 fallback 成两步操作，中间挂掉就留死锁。
value 必须是每个 goroutine 独立生成的随机字符串，比如
，不能复用固定值或时间戳
ttl 不是随便拍的：设为业务 P99 耗时 × 2～3，例如导出任务 P99 是 1.8s，那就设
key 建议带业务上下文前缀，如
，避免跨服务误删
Lua 脚本释放锁是防误删的硬门槛
用
判断再
是经典竞态：A 查到锁存在，正要删，B 已抢到并写入新值，A 一删就把 B 的锁干掉了。唯一可靠方式是 Lua 脚本原子执行：
Go 中调用：
，返回非
就代表释放失败，必须记录日志或告警，不能静默忽略。
脚本别拼在代码里，用
或
管理，方便灰度和审计
如果返回
，说明 key 不存在或值不匹配——不是成功，是失败
别在 defer 里无条件调用释放，得先判断自己是否真持有锁（比如通过 context.Done() 或显式标志）
自动续期不是可选功能，而是保命机制
GC 暂停、网络抖动、磁盘 I/O 延迟都可能让业务执行超过 TTL。不续期 = 锁提前丢失 = 并发写入风险。续期必须满足两个条件：只续自己的锁、间隔合理。
立即学习
“
go语言免费学习笔记（深入）
”；
续期脚本也得用 Lua：
续期间隔建议为 TTL / 3，比如 TTL=3s，就每 1s 续一次；太密压 Redis，太疏容易掉锁
启动续期 goroutine 后，业务函数
前必须显式
对应 context，否则变成“幽灵续期”——锁早释放了，后台还在给一个不存在的 key 续期
多节点公平性靠客户端逻辑兜底，Redis 本身不保证
Redis 没有队列、没有优先级、不记录等待者顺序。所谓“公平”，只能靠客户端实现重试退避 + 随机 jitter。直接轮询
会引发 thundering herd，把 Redis 打满。
首次抢锁失败后，不要立即重试，用
加随机抖动
连续失败 3 次后，考虑指数退避，但上限别超业务超时时间
如果业务允许，把锁 key 设计成带 hash tag 的格式，如
，确保 Redis Cluster 下 key 落在同一 slot，避免 MOVED 重定向开销
真正需要强公平语义（比如金融类调度），别硬刚 Redis——换 etcd，用
配合租约，它的 Raft 日志天然支持线性一致的排队效果
真实场景中，最易被忽略的是「锁释放后的状态清理」：续期 goroutine 的 cancel、context 的生命周期绑定、以及释放失败时的 fallback 处理（比如降级为本地限流或直接报错）。这些细节不写进主流程，只靠注释或文档，上线后必出问题。
SetNXSET key value PX 30000 NXSET key value EX 30 NXgo-redis/v9client.Set(ctx, key, value, ttl)NXPXuuid.NewString()4 * time.Secondlock:order:789GETDELif redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("del", KEYS[1])
else
return 0
endunlockScript.Run(ctx, rdb, []string{key}, lockValue)1//go:embedconstredis.Nilif redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("pexpire", KEYS[1], ARGV[2]) else return 0 endreturncancel()SET ... NXtime.Sleep(time.Millisecond * (50 + rand.Int63n(100))){lock:order}:789clientv3.Txn().If(...).Then(...).Else(...)