缓存击穿：当热点Key失效时，数据库如何扛住“万箭齐发”？
先明确一个核心概念：缓存击穿，它既不是大面积的缓存雪崩，也不是针对不存在数据的缓存穿透。它更像一次精准的“斩首行动”——当某个万众瞩目的热点Key在Redis中过期的那一刹那，海量并发请求瞬间发现缓存失效，齐刷刷地涌向MySQL，足以在顷刻间让数据库压力飙升。典型的场景？想想秒杀商品的详情页、实时更新的热搜榜单，或者配置中心里被高频读取的核心参数。
问题的根源，往往就藏在最常用的EXPIRE或SETEX命令里。为Key设置一个固定的生存时间（TTL）看似合理，但一旦这个过期时间点与流量洪峰不期而遇，后果可想而知。
为什么逻辑过期比物理过期更合适高并发场景
物理过期依赖Redis自动删除Key，时机完全不可控。而逻辑过期则玩了个“障眼法”：它把真正的过期时间“藏”进Value里。比如，存储一个JSON结构：{"data": "...", "expireAt": 1717023600000}。这样一来，Redis的Key本身设置为永不过期，由应用程序在读取Value后，自行判断内嵌的expireAt时间戳是否已过，再决定是否触发异步的缓存重建。
这个设计的妙处在于，它从根本上瓦解了“所有请求在同一毫秒发现Key消失”的同步性，天然实现了请求的“削峰填谷”。
当然，有几个细节必须敲黑板：
- 互斥锁是标配：必须配合类似
SET key value NX PX 5000这样的分布式锁，防止多个线程同时判断过期后，重复进行数据库回源查询。 - 时间戳用绝对的：
expireAt建议使用毫秒级的绝对时间戳，而不是相对的秒数。这样可以避免因服务器时钟漂移或服务重启带来的时间误判。 - 更新要原子化：更新缓存时，必须原子性地替换整个Value（包含新的
expireAt），切忌只更新数据部分而忘了过期时间。
一个安全的逻辑过期读取流程（Ja va + Jedis 示例）
这里的核心，不在于代码怎么写，而在于哪几个环节一旦缺失保护就必然出问题：
- 第一步，解析与判断：从Redis
GET到值后，务必解析JSON并检查expireAt < System.currentTimeMillis()。别忘了前置的null判断。 - 第二步，竞争与降级：若数据已逻辑过期，尝试用
SET lock_key random_value NX PX 30000争抢锁。抢锁失败的线程，应直接返回旧的缓存数据（允许短暂的数据延迟），这是一种有效的降级策略。只有抢锁成功的线程，才负责查询数据库并更新缓存。 - 第三步，重建与更新：写入新缓存时，
expireAt应设置为“当前时间 + 业务期望的缓存时长”（例如10分钟），切勿图省事复用旧的过期时间。 - 第四步，锁的释放：务必通过执行Lua脚本（
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对应的核心业务表加上监控。重点关注
Rows_examined（扫描行数）指标，如果该指标在缓存失效后突然飙升，大概率是回源SQL没有命中预期索引，需要立即介入优化。
说到底，逻辑过期方案真正的难点，往往不在于代码的实现。而在于一系列工程决策：哪些Key值得用逻辑过期？expireAt设置多长才合理？锁的超时时间如何与缓存重建耗时匹配？这些问题，没有放之四海而皆准的模板，只能依靠线上的压力测试、慢查询日志的持续分析和业务场景的反复打磨，才能找到最优解。
