分布式锁必须用SET key value EX seconds NX原子命令加锁，因SET会覆盖旧值破坏互斥性；解锁需Lua脚本校验value再删，防止误删他人锁；续期须原子校验+重设过期；Redlock非必需，单实例配合合理机制已足够可靠。
为什么不能直接用 SET key value 加锁
直接用 SET 设置键值会覆盖旧值，无法保证“仅当锁不存在时才设置成功”——这正是分布式锁的核心前提。如果两个客户端同时执行 SET lock:order 123，都成功，就出现双持锁，业务逻辑就乱了。
必须用原子命令确保“存在则失败，不存在则写入+设置过期”。Redis 提供 SET key value EX seconds NX（或 PX）组合，其中 NX 表示 only if Not eXists，EX 避免死锁。
-
NX和XX互斥，别混用；EX和PX也互斥，按秒还是毫秒选一个 - 过期时间不能设太短（业务没执行完锁就释放），也不能太长（故障后恢复慢）；建议比最长业务耗时多 20%～50%
- value 必须是唯一标识（如 UUID 或 clientID+threadID），后续解锁时靠它校验所有权
解锁时为什么不能只用 DEL key
直接 DEL lock:order 会删掉别人持有的锁。比如 A 拿到锁，但执行慢超时自动释放了，B 趁机获取并开始执行；此时 A 终于完成，一拍脑袋 DEL，结果把 B 的锁干掉了。
解锁必须校验 value 是否匹配，再删除——这个操作要原子。Redis 没有内置“校验+删”命令，得用 Lua 脚本：
if redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("del", KEYS[1])
else
return 0
end
调用时传入 EVAL ... 1 lock:order abc-def-123，脚本里 KEYS[1] 是 key，ARGV[1] 是持有者标识。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- Lua 脚本在 Redis 单线程中执行，天然原子，不用加额外同步
- 别用客户端先
GET再DEL—— 中间可能被别人篡改，这就是经典的 check-then-act 竞态 - 脚本返回 1 表示成功删除，0 表示非持有者调用，应视为解锁失败
锁续期（renew）怎么做才安全
业务执行时间不确定，但锁又不能无限期续——否则节点宕机后锁永远不释放。需要后台线程定期延长锁的过期时间，前提是“自己还持有锁”。
续期本质是：校验当前 value 是否匹配 + 重设过期时间。同样得用 Lua 保证原子性：
if redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("expire", KEYS[1], ARGV[2])
else
return 0
end
例如每 1/3 过期时间触发一次续期，新过期时间设为原值（不是叠加）。
- 续期间隔建议 ≤ 锁过期时间 / 3，留出网络和执行缓冲
- 不要用
SETEX或SET ... XX，它们不检查 value，会覆盖别人持有的锁 - 一旦业务完成或异常退出，必须主动停掉续期任务，避免无效续期干扰其他客户端
Redlock 真的比单实例更可靠吗
Redlock（多个独立 Redis 实例取多数派）听起来防止单点故障，但实际引入更多问题：时钟漂移、网络分区下误判、实现复杂度高。Redis 官方后来也弱化了 Redlock 推荐。
对大多数服务，用单个 Redis（主从+哨兵或 Cluster）配合合理的锁超时、续期、唯一 value 校验，已足够可靠。真正瓶颈往往不在锁本身，而在下游依赖（DB 响应慢、HTTP 调用卡住）导致锁持有时间不可控。
- 别为了“理论强一致性”硬上 Redlock，先压测单实例锁在真实流量下的失败率
- 集群模式下注意 key slot 分布——
lock:user:123这种 key 要用{user:123}手动哈希到同一 slot，否则EVAL脚本跨 slot 会报错 - 锁只是协调手段，关键路径上优先考虑无锁设计（如幂等写、状态机、消息队列削峰）
