Redis缓存击穿时，为什么要限制缓存回源的并发数？

互斥锁（SETNX）可有效防止缓存击穿：仅首个请求回源查DB，其余等待或轮询，避免N次重复查询压垮数据库；需设锁过期时间防死锁，锁key须与业务key分离且唯一。

不加限制，数据库会在毫秒内被压垮

缓存击穿时的并发回源行为本质是“重复查询”

当 key 过期后，所有请求同时发现缓存缺失，都会执行 db.query(key) —— 这不是“一次查、多路分发”，而是 N 个请求各自独立发起 SQL 查询。哪怕数据完全相同，数据库也得执行 N 次全链路处理（连接池分配、SQL 解析、执行计划、IO 等）。

常见错误现象：MySQL Too many connections、Connection timeout、慢查询堆积、CPU 瞬间打满。

1. 数据库连接池通常默认 10–100，而并发请求可能达 1000+
2. 即使连接池能扩容，磁盘 IO 和锁竞争也会成为瓶颈
3. 应用层重试逻辑会进一步放大压力（如超时后重发）

用 SETNX 实现互斥锁是最轻量的控制手段

Redis 的 SETNX 命令天然适合做“抢占式锁”：只有第一个成功设置 key_mutex 的请求才能回源，其余请求要么等待、要么轮询检查缓存是否写入完成。

关键参数注意点：

1. key_mutex 的过期时间必须设（比如 30 秒），避免死锁（进程崩溃未释放锁）
2. 不要用 DEL + SET 组合替代 SETNX，存在竞态漏洞
3. 轮询等待时建议加 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 失效；数据库行锁对非主键查询无效，且锁粒度大、开销高。

真正有效的约束必须满足三个条件：

1. 跨 JVM 进程可见（所以必须依赖 Redis 或 ZooKeeper 等共享存储）
2. 操作具备原子性（SETNX 是 Redis 原生命令，无中间状态）
3. 失败路径可兜底（锁超时自动释放，避免雪崩式阻塞）

如果业务允许少量冗余查询，也可以用“逻辑过期”方案：缓存值里嵌入一个 expire_at 字段，过期只触发异步更新，读请求仍返回旧值 —— 但这要求业务能接受短暂脏读。

最容易被忽略的点是：锁 key 和业务 key 必须分离，且锁 key 要带唯一标识（比如 lock:product:1001），否则不同商品可能误锁同一资源。