缓存击穿会导致数据库崩溃，因其本质是热点key过期瞬间大量请求直击db，而db无法承受毫秒级高并发查询；逻辑过期通过在value中存储expiretime字段并配合互斥锁实现串行加载，避免穿透。
缓存击穿为什么会让数据库崩
缓存击穿本质是「单个热点 key 过期瞬间，大量并发请求同时穿透 Redis 直击 DB」。Redis 单线程响应快，但 DB 是 IO 密集型，扛不住同一毫秒级涌来的几百上千次查询。尤其像商品详情、活动页这类数据，零点一过 key 失效，所有请求就排队打 DB，连接池耗尽、慢 SQL 积压、CPU 爆表——崩得干脆利落。
逻辑过期不是设置 EXPIRE，而是把过期时间藏进 value 里
物理过期（EXPIRE）一到，key 真没了，Redis 直接返回 nil；逻辑过期则是：value 本身是 JSON 或 Hash 结构，里面显式存一个 expireTime 字段（比如时间戳），应用层自己判断是否“该过期了”。Redis 不管它，key 永远存在（或设极长 TTL 防误删）。
这样做能避免 key 突然消失引发的并发穿透。实操要点：
-
SET写入时，value 包含业务数据 +expireTime字段，例如：{"data":"{...}","expireTime":1744525680000} - 读取时，先
GET出整个 value，解析 JSON，比对当前时间与expireTime - 若已过期，不直接删 key，而是尝试用
SETNX抢一个互斥锁（如lock:goods:1001），抢到才去查 DB 并更新 value 和expireTime - 抢锁失败的请求，可选择等待重试（需设超时，比如
Thread.sleep(50)后再读一次）或直接返回旧值（容忍短暂 stale）
为什么不用 EXPIRE 而要自己管过期逻辑
因为 EXPIRE 是原子操作，但无法触发“自动刷新”动作。一旦 key 过期，所有并发请求看到的都是空，只能各自去 DB 查——这正是击穿根源。而逻辑过期把“是否需要刷新”的判断权交还给业务代码，天然支持串行化加载：
- DB 查询和缓存更新被锁保护，只允许一个线程执行
- 其他线程看到的是“逻辑过期但物理未删”的旧数据，有兜底，不打 DB
- 避免了分布式锁的释放异常问题（比如进程崩溃导致锁不释放）：即使锁没释放，下次过期后仍能靠
SETNX重新抢到 - 注意：
expireTime必须用绝对时间戳（毫秒），别用相对秒数，否则多实例时钟不同步会导致误判
逻辑过期 + 互斥锁的实际陷阱
看似稳妥，但几个细节不处理好，照样翻车：
- 锁 key 的生命周期必须短于业务查询耗时，否则等待线程全卡死。建议
SETNX lock:xxx 1 EX 30，30 秒是硬上限 - 更新 value 时，不能只
SET新值，必须保证expireTime字段也一并更新，否则下次读还是走旧逻辑 - 如果 DB 查询失败（网络抖动、SQL 报错），必须删掉锁并返回旧值，不能让锁一直占着——否则后续所有请求都等死
- 别忘了给锁加前缀隔离环境，比如测试环境用
lock:test:goods:1001，避免和线上冲突
逻辑过期不是银弹，它把“击穿风险”转成了“数据短暂不一致”，但换来的是 DB 的稳定。真正难的不是写这段代码，而是想清楚：你的业务能不能接受最多 30 秒的脏读？如果不能，就得搭配定时预热或双缓存机制。
