不成立。Redis集群模式下SET key value NX PX因跨slot路由失败而无法保证原子性，必须改用Redlock算法，即向多数独立master节点并发加锁并逐节点释放，且需使用单节点客户端而非ClusterClient。
Redis集群下SET命令的NX+PX原子性是否还成立
不成立。Redis集群（Cluster）模式下，SET key value NX PX 10000 会直接报错 MOVED 或 CROSSSLOT，因为该命令涉及单个key，但集群会按slot路由，而客户端若未正确哈希定位到目标节点，就无法保证原子执行。
根本原因：集群中key被分散到不同master节点，而SET ... NX PX 是单节点原子命令，无法跨slot或跨节点协调。你不能指望集群自动把这条命令转发到正确的节点并保证原子性——它要么失败，要么被客户端库静默重试（但重试不等于原子）。
- go-redis/v8 默认启用集群模式时，遇到不支持的命令会返回
redis: command not allowed in cluster mode或类似错误 - redsync/v4 底层依赖
client.SetNX()，在集群 client 上调用会 panic 或返回 nil，除非你手动指定 slot-aware 的 client（比如用cluster.Client的Do()绕过高层封装） - 真正可行的路径只有两条：改用单节点 Redis（含哨兵 failover），或改用 Redlock 算法（需至少 3 个独立 master 节点，且容忍 ≤1 个故障）
用 go-redis/v8 在集群模式下安全加锁的唯一可行方式
放弃「单 key + NX+PX」幻想，改用 Redlock 协议实现。这不是可选项，是集群环境下的强制要求。
Redlock 核心逻辑：向 ≥N/2+1 个独立 Redis master 同时尝试加锁（每个都用 SET key value NX PX），全部成功才算拿到锁；释放锁时，必须向所有曾成功加锁的节点发 Lua 删除脚本。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- go-redis/v8 自带
redis.NewClusterClient()，但它不提供 Redlock 原生支持，需配合 redsync/v4 使用 - redsync/v4 初始化时必须传入多个独立的
*redis.Client（不是*redis.ClusterClient），每个指向不同 master 的地址，例如：[]*redis.Client{c1, c2, c3} - 务必确认这些 client 都是单节点模式（
redis.NewClient()），否则 redsync 会在底层调用SetNX时崩溃 - redsync 默认超时是 2s，但集群网络延迟更高，建议显式设置：
redsync.NewPool(pool, redsync.WithTimeout(5*time.Second))
解锁时 Lua 脚本必须逐节点执行，不能只删一个
Redlock 要求释放锁时，对每一个曾成功加锁的 Redis 节点，都单独执行一次 Lua 脚本。漏掉任何一个，就可能留下残留锁。
redsync/v4 的 mutex.Unlock() 内部已实现该逻辑——它会遍历当初加锁成功的节点列表，逐个调用 client.Eval()。但前提是：你没手动替换或劫持它的 unlock 流程。
- 别在业务代码里直接调用
client.Del(key)，这会绕过 redsync 的节点跟踪机制 - 别复用同一个
mutex实例跨请求——Gin 中每个 HTTP 请求必须新建 mutex：mutex := pool.NewMutex("order:123") - 如果 unlock 返回 error（比如某个节点网络不通），redsync 默认忽略；但生产环境建议记录 warn 日志，因为残留锁可能影响后续请求
Gin 中绑定锁生命周期到 request context 的实操要点
锁必须随请求结束而释放，否则集群里一堆半死不活的锁会拖垮系统。Gin 的 c.Request.Context() 是唯一可靠锚点。
- 加锁前用
ctx, cancel := context.WithTimeout(c.Request.Context(), 3*time.Second)，避免阻塞整个 goroutine - 加锁成功后，用
defer func() { mutex.Unlock() }()，但必须确保 defer 在 handler 函数内，不能提前提到中间件外层 - 禁止把
mutex存进 Gin 的c.Set("mutex", m)然后在其他地方取——value 不唯一，不同请求会覆盖 - 更稳妥的做法是：锁 key 拼接请求唯一标识，比如
"lock:" + c.Param("id") + ":" + uuid.NewString()，避免 key 冲突
