缓存击穿是指热点key在Redis中过期瞬间，大量请求同时击穿至MySQL导致瞬时压力激增；其本质是物理过期引发的并发回源问题，逻辑过期通过将过期时间嵌入value并配合互斥锁可有效规避。
缓存击穿在 Redis + MySQL 场景下到底是什么
缓存击穿不是缓存雪崩，也不是缓存穿透，它特指：某个热点 key 在 Redis 中过期的瞬间，大量并发请求同时发现缓存 miss，全部打到 MySQL，造成数据库瞬时压力激增。典型场景是秒杀商品详情页、热搜榜单、配置中心的高频读 key。
用 EXPIRE 或 SETEX 设置固定 TTL 是最常见诱因——一旦过期时间撞上流量高峰，MySQL 就可能被压垮。
为什么逻辑过期比物理过期更合适高并发场景
物理过期（Redis 自动删 key）不可控；逻辑过期是把过期时间“藏”在 value 里，比如存一个 JSON：{"data": "...", "expireAt": 1717023600000}。Redis key 本身永不过期，应用层读取后判断 expireAt 是否已过，再决定是否异步重建缓存。
这样做能彻底避免“所有请求在同一毫秒发现 key 消失”的问题，天然削峰。
注意点：
- 必须配合互斥锁（如
SET key value NX PX 5000）防止多个线程同时回源，否则仍可能重复查库 -
expireAt建议用毫秒时间戳而非相对秒数，避免时钟漂移或服务重启导致误判 - 更新缓存时要原子更新整个 value（含新
expireAt），不能只改 data 字段
一个安全的逻辑过期读取流程（Java + Jedis 示例）
核心不是“怎么写代码”，而是“哪几处不加保护就必出问题”：
- 第一次
GET到值后，必须解析 JSON 并检查expireAt ，别漏掉 null 判断 - 若已逻辑过期，用
SET lock_key random_value NX PX 30000尝试争锁；失败则直接返回旧值（允许短暂脏读），成功才查 DB +SET新 value - 写入新缓存时，
expireAt应设为当前时间 + 业务期望 TTL（比如 10 分钟），别复用旧值 - 务必设置锁释放的
EVAL脚本防误删（用random_value校验），否则其他线程可能删掉别人刚设的锁
// 伪代码关键片段
String cacheJson = jedis.get("item:1001");
if (cacheJson != null) {
CacheData data = parse(cacheJson);
if (data.expireAt > System.currentTimeMillis()) {
return data.data;
}
}
// 逻辑过期，尝试加锁重建
String lockKey = "lock:item:1001";
String requestId = UUID.randomUUID().toString();
if ("OK".equals(jedis.set(lockKey, requestId, "NX", "PX", 30000))) {
try {
Object dbResult = loadFromDb(1001);
String newJson = buildCacheJson(dbResult, 10*60*1000); // 新 expireAt
jedis.set("item:1001", newJson);
} finally {
unlock(lockKey, requestId); // 用 Lua 校验再 del
}
}
return getFromCacheOrOldValue(); // 返回旧值或重试
MySQL 侧需要配合做的三件事
光靠 Redis 逻辑过期不够，MySQL 层没配合，照样会慢甚至死锁：
- 所有被缓存的查询必须走覆盖索引，禁止
SELECT *，否则二级索引回表在高并发下极易成为瓶颈 - 对缓存重建所用的 SQL，加上
FOR UPDATE要慎之又慎——除非你真需要强一致性；多数场景用快照读（默认隔离级别）即可，避免行锁升级成间隙锁阻塞其他查询 - 给缓存 key 对应的业务表加监控：当单条 SQL 的
Rows_examined突增，大概率是缓存失效后回源 SQL 没走索引，得立刻干预
逻辑过期真正难的不是代码实现，是判断哪些 key 值得加、expireAt 设多长、锁超时和重建耗时如何匹配——这些只能靠线上压测和慢日志反推，没法靠模板解决。
