SET命令通过EX+NX原子性实现带过期时间的互斥锁，value须唯一、过期时间需长于重建耗时，释放锁必须用Lua脚本校验所有权，加锁失败应轮询缓存而非直查DB，单点Redis锁需配合Redlock或本地缓存降级。
用 SET 命令实现带过期时间的原子互斥锁
缓存击穿本质是热点 key 过期瞬间大量请求穿透到 DB，互斥锁要解决的是“谁来重建缓存”的竞争问题。Redis 本身没有原生分布式锁，但 SET 的 EX + NX 组合能原子性地完成“设值且仅当不存在时成功”，这才是可靠起点。
常见错误是先 GET 再 SET，这中间存在竞态窗口；或者只用 SETNX（已废弃），不设过期时间，一旦客户端崩溃锁就永久残留。
-
SET key "lock_value" EX 30 NX—— 必须同时指定过期时间（如 30 秒）和NX，避免死锁 - value 不能写死（如
"1"），得用唯一标识（如 UUID 或进程 ID + 时间戳），后续释放锁时可校验所有权 - 过期时间要明显长于缓存重建耗时（比如重建最多 2 秒，那就设 10 秒以上），否则锁提前释放会导致多个客户端同时重建
释放锁必须用 Lua 脚本保证原子性
判断 value 相等再 DEL 看似合理，但 GET 和 DEL 是两个命令，中间可能被其他客户端修改。一旦误删别人持有的锁，就会引发并发重建。
正确做法是把“校验 value + 删除”封装进一段 Lua 脚本，由 Redis 单线程执行，天然原子：
if redis.call("GET", KEYS[1]) == ARGV[1] then
return redis.call("DEL", KEYS[1])
else
return 0
end
调用时传入 key 和你生成的唯一 value，返回 1 表示释放成功，0 表示锁不属于当前客户端。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
加锁失败后不能直接回退到 DB 查询
典型误区：A 加锁成功去查 DB、重建缓存；B/C/D 同时加锁失败，就立刻各自去查 DB——这等于没锁住，击穿照旧。
必须让未获得锁的请求等待并重试，直到缓存被填上：
- 用
GET循环轮询目标缓存 key，直到非空或超时（比如最多等 500ms） - 轮询间隔建议 10–50ms，避免密集打满 Redis
- 如果超时仍未命中，再降级查 DB（此时大概率已有其他客户端写入，但兜底必须有）
- 注意别让轮询逻辑阻塞主线程，异步或协程更稳妥
Redis 单点故障会放大锁失效风险
用单个 Redis 实例做锁服务，一旦它宕机，所有锁立即丢失，重建逻辑全量并发。这不是理论风险——主从切换期间、RDB 持久化卡顿都可能导致短暂不可用。
生产环境不能依赖单一 Redis 实例的锁：
- 优先考虑 Redlock（需 5 个独立实例，多数派成功才算加锁），但要注意它对时钟漂移敏感，且在分区网络下仍有边界问题
- 更务实的做法是：锁仅用于“降低并发度”，不追求强一致；配合本地缓存（如 Caffeine）做二级保护，减少对 Redis 锁的绝对依赖
- 监控
SET失败率和锁等待时长，异常升高往往意味着 Redis 延迟突增或锁设计不合理
真正难处理的不是锁怎么写，而是锁失效后如何不让 DB 被打垮——重试策略、降级开关、DB 连接池限流，这些都得和锁联动设计。
