Redis如何处理分布式环境下缓存击穿的互斥锁竞争-Redis-PHP中文网

set命令通过ex+nx原子性实现带过期时间的互斥锁，value须唯一、过期时间需长于重建耗时，释放锁必须用lua脚本校验所有权，加锁失败应轮询缓存而非直查db，单点redis锁需配合redlock或本地缓存降级。

redis如何处理分布式环境下缓存击穿的互斥锁竞争

缓存击穿本质是热点 key 过期瞬间大量请求穿透到 DB，互斥锁要解决的是“谁来重建缓存”的竞争问题。Redis 本身没有原生分布式锁，但 SET 的 EX + NX 组合能原子性地完成“设值且仅当不存在时成功”，这才是可靠起点。

常见错误是先 GET 再 SET，这中间存在竞态窗口；或者只用 SETNX（已废弃），不设过期时间，一旦客户端崩溃锁就永久残留。

判断 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 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

典型误区：A 加锁成功去查 DB、重建缓存；B/C/D 同时加锁失败，就立刻各自去查 DB——这等于没锁住，击穿照旧。

必须让未获得锁的请求等待并重试，直到缓存被填上：

用单个 Redis 实例做锁服务，一旦它宕机，所有锁立即丢失，重建逻辑全量并发。这不是理论风险——主从切换期间、RDB 持久化卡顿都可能导致短暂不可用。

生产环境不能依赖单一 Redis 实例的锁：

真正难处理的不是锁怎么写，而是锁失效后如何不让 DB 被打垮——重试策略、降级开关、DB 连接池限流，这些都得和锁联动设计。

Redis如何处理分布式环境下缓存击穿的互斥锁竞争