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

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

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

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

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

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

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

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

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

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

三、两种方案的执行流程对比（更直观）

1. 单纯互斥锁（物理过期）的执行流程

核心问题：缓存过期后，所有请求都要等锁释放，会出现请求堆积、接口响应慢的情况。

2. 逻辑过期 + 互斥锁的执行流程

• 核心优势：无论是否抢到锁，都立刻返回旧数据，接口无阻塞，只有1个异步线程去更新缓存。

四、关键补充：两种方案的“锁”作用不同

• 单纯互斥锁：锁的是“查数据库的权限”——因为缓存空了，必须保证只有一个请求查库，否则就击穿；
• 逻辑过期 + 互斥锁：锁的是“更新缓存的权限”——缓存还在（有旧数据），只是要更新，保证只有一个请求去更新，其他请求先用旧数据。

总结

• 逻辑过期加互斥锁，是为了防止缓存过期后大量请求同时触发缓存更新，避免数据库被异步更新请求压垮；
• 和单纯互斥锁的核心区别：逻辑过期方案不删除缓存、返回旧数据、无请求阻塞，而单纯互斥锁会删除缓存、等待锁释放、返回最新数据；
• 选型原则：对实时性要求低、追求高并发高可用选“逻辑过期 + 锁”，对实时性要求高选“单纯互斥锁”。

通俗解释二者区别

单纯互斥锁方案：缓存物理过期后在Redis里被删除，请求发现没缓存，就抢互斥锁去更新数据库，其他线程等待或重试，直到拿到锁的线程更新完缓存，所有请求才能读到新数据。这种方案能保证缓存和数据库完全一致，但代价是过期瞬间的请求会卡住。

逻辑过期方案：缓存不设物理过期时间，但带一个逻辑过期字段。由于Redis里数据永久存在，所有请求进来先判断逻辑是否过期。如果过期，只有一个请求拿互斥锁去更新缓存，其余请求直接返回旧的缓存数据，不会阻塞。代价是缓存和数据库存在短暂不一致。

另外，单纯互斥锁不要求提前预热缓存——没有缓存就直接查数据库。但逻辑过期必须提前预热缓存数据，因为它的核心是“缓存始终有数据，哪怕是旧数据”。如果不预热，逻辑过期方案根本没意义。