互斥锁解决缓存击穿需避免裸用setnx，应结合phpredis原生锁、双重检查和分层退避：设px过期、lua原子删锁、首次检查缓存，加锁后二次检查，再查库写缓存；锁密钥须随机唯一，逻辑过期需存数据+时间戳。
互斥锁能解决缓存击穿，但直接用 SETNX + 轮询重试是最容易出问题的写法。 真正稳定的做法是结合 phpredis 原生锁机制、双重检查（double-check）和合理退避，否则极易陷入死锁、锁失效或线程饥饿。
phpredis 的 setnx 为什么不能裸用
很多人直接写 if ($redis->setnx($mutexKey, 1)) { ... }，但这忽略了三个关键事实：
- 没有设置过期时间 → 一旦进程崩溃或异常退出，
$mutexKey永久存在，后续所有请求都被阻塞 - 没有原子性释放逻辑 → 用
DEL删除锁时，可能删掉别人持有的锁（A 拿到锁，B 超时后也拿到锁，A 执行完 DEL 掉 B 的锁） - 没有重试策略控制 → 高并发下大量线程同时轮询
GET缓存 +SETNX，Redis QPS 瞬间翻倍，反而加剧压力
phpredis 内置的会话锁机制（redis.session.locking_enabled）已封装了带 PX 过期、LUA 原子释放、重试间隔等细节，比手写更可靠。
必须做两次缓存检查（double-check）
这是避免重复重建和降低等待开销的核心。流程不是「没缓存 → 加锁 → 查库 → 写缓存」，而是：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 第一次检查：
$value = $redis->get($key)，命中则直接返回 - 未命中时，尝试获取互斥锁（例如用
$redis->set($mutexKey, $secret, ['NX', 'PX' => 30000])） - 获取成功后，**立刻再次检查缓存**：
$value = $redis->get($key)—— 因为可能在你拿锁的几十毫秒内，另一个刚释放锁的线程已经写入了新值 - 只有二次检查仍为空，才查库、写缓存、释放锁
漏掉第二次检查，会导致多个线程在极短时间内先后拿到锁并重复执行 DB 查询，失去互斥意义。
退避策略不是“简单 sleep”，而是分层响应
拿不到锁时，不能统一 sleep(100)。不同场景应差异化处理：
- 首次失败：立即重试
GET，不 sleep（网络延迟或短暂竞争） - 连续 2 次失败：
usleep(5000)（5ms），避免毛刺干扰 - 超过 3 次：改用指数退避，如
usleep(pow(2, $retry) * 1000)，上限封顶在 50ms - 总等待超 200ms 或重试超 5 次 → 直接返回空或兜底数据，防止请求堆积
phpredis 的 redis.session.lock_wait_time（默认 20000 微秒）只控制单次锁等待，不替代业务层的重试逻辑 —— 它只是底层连接级超时，不是业务重试策略。
最易被忽略的是锁密钥（$secret）的唯一性：必须是当前进程/请求可生成且不可预测的随机值（如 bin2hex(random_bytes(16))），否则多个实例可能误删彼此的锁；还有就是逻辑过期方案里，value 结构要包含真实数据 + 逻辑过期时间戳，不能只存字符串。
