首页 > 数据库 >缓存击穿：逻辑过期与单纯互斥锁的区别说明

缓存击穿：逻辑过期与单纯互斥锁的区别说明

来源：互联网 2026-07-07 09:07:02

一、逻辑过期中加互斥锁的核心原因逻辑过期的设计哲学是“过期不删缓存，先返回旧数据再说”。但这里有一个容易被忽视的陷阱：一旦缓存逻辑过期，所有请求都会触发更新缓存的逻辑。就算你用了异步线程，也会瞬间产生大量异步任务同时去查数据库、更新缓存。说白了，就是把本来同步请求冲击数据库的压力，换成了异步线程冲击

一、逻辑过期中加互斥锁的核心原因

逻辑过期的设计哲学是“过期不删缓存，先返回旧数据再说”。但这里有一个容易被忽视的陷阱：一旦缓存逻辑过期，所有请求都会触发更新缓存的逻辑。就算你用了异步线程，也会瞬间产生大量异步任务同时去查数据库、更新缓存。说白了，就是把本来同步请求冲击数据库的压力，换成了异步线程冲击数据库——数据库照样扛不住。

举一个具体的缓存击穿场景：

长期稳定更新的攒劲资源： >>>点此立即查看<<<

秒杀商品的缓存逻辑过期了，瞬间涌进1000个请求；
如果不加锁：这1000个请求全部触发异步更新，1000个线程同时查数据库里的商品库存，数据库直接崩溃；
如果加互斥锁：只有1个请求能拿到锁，触发1次异步更新，剩下的999个请求直接返回旧数据，数据库只承受1次查询压力。

所以，逻辑过期里的互斥锁，目标非常明确——限制“更新缓存”的操作只能由单个请求执行，彻底杜绝数据库被大量更新请求冲击。这是逻辑过期方案能防缓存击穿的“最后一道保障”。

二、逻辑过期（加锁） vs 单纯互斥锁（防缓存击穿）的核心区别

先理清单纯用互斥锁防缓存击穿的常规逻辑：

缓存物理过期（Redis自动删除）→ 请求进来发现缓存空 → 抢锁 → 抢到锁的查数据库、更新缓存 → 没抢到锁的等待/重试 → 最终拿到新缓存数据。

两种方案的核心差异，用表格对比一目了然：

维度	逻辑过期 + 互斥锁	单纯互斥锁（物理过期）
缓存是否被删除	物理永不过期（只判断逻辑过期时间）	物理过期（Redis自动删除缓存）
过期后请求的返回值	直接返回旧数据（不阻塞）	没抢到锁的请求会等待/重试（阻塞）
数据一致性	短暂返回旧数据（最终会更新）	拿到的都是最新数据（无脏数据）
接口响应速度	极快（无论是否过期，都快速返回）	过期瞬间的请求会有等待（响应慢）
适用场景	热点key、对实时性要求低、追求高可用（如首页）	数据实时性要求高、可接受短暂阻塞