互斥锁（SETNX）可有效防止缓存击穿：仅首个请求回源查DB，其余等待或轮询，避免N次重复查询压垮数据库；需设锁过期时间防死锁，锁key须与业务key分离且唯一。
不加限制，数据库会在毫秒内被压垮
缓存击穿时的并发回源行为本质是“重复查询”
当 key 过期后，所有请求同时发现缓存缺失，都会执行 db.query(key) —— 这不是“一次查、多路分发”，而是 N 个请求各自独立发起 SQL 查询。哪怕数据完全相同，数据库也得执行 N 次全链路处理（连接池分配、SQL 解析、执行计划、IO 等）。
常见错误现象：MySQL Too many connections、Connection timeout、慢查询堆积、CPU 瞬间打满。
- 数据库连接池通常默认 10–100，而并发请求可能达 1000+
- 即使连接池能扩容，磁盘 IO 和锁竞争也会成为瓶颈
- 应用层重试逻辑会进一步放大压力（如超时后重发）
用 SETNX 实现互斥锁是最轻量的控制手段
Redis 的 SETNX 命令天然适合做“抢占式锁”：只有第一个成功设置 key_mutex 的请求才能回源，其余请求要么等待、要么轮询检查缓存是否写入完成。
关键参数注意点：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
key_mutex的过期时间必须设（比如30秒），避免死锁（进程崩溃未释放锁） - 不要用
DEL + SET组合替代SETNX，存在竞态漏洞 - 轮询等待时建议加
Thread.sleep(10)或指数退避，别空转
示例伪代码逻辑：
if redis.get(key) == null:
if redis.setnx(key_mutex, "1", expire=30):
value = db.query(key)
redis.set(key, value, expire=300)
redis.delete(key_mutex)
else:
while redis.exists(key_mutex):
sleep(10)
return redis.get(key)
为什么不用数据库行锁或应用层 synchronized？
分布式环境下，单机 synchronized 失效；数据库行锁对非主键查询无效，且锁粒度大、开销高。
真正有效的约束必须满足三个条件：
- 跨 JVM 进程可见（所以必须依赖 Redis 或 ZooKeeper 等共享存储）
- 操作具备原子性（
SETNX是 Redis 原生命令，无中间状态） - 失败路径可兜底（锁超时自动释放，避免雪崩式阻塞）
如果业务允许少量冗余查询，也可以用“逻辑过期”方案：缓存值里嵌入一个 expire_at 字段，过期只触发异步更新，读请求仍返回旧值 —— 但这要求业务能接受短暂脏读。
最容易被忽略的点是：锁 key 和业务 key 必须分离，且锁 key 要带唯一标识（比如 lock:product:1001），否则不同商品可能误锁同一资源。
