缓存击穿是热点key过期瞬间大量请求涌向数据库导致崩溃，需用SET NX原子锁或逻辑过期双保险解决，布隆过滤器对此无效。

缓存击穿到底是什么，为什么它专挑高并发时出事

缓存击穿不是缓存没命了，而是某个 key 过期瞬间，大量请求同时发现缓存里没有，一股脑涌向数据库——数据库扛不住就抖、慢、甚至挂。它和缓存穿透（查根本不存在的 key）、雪崩（大批 key 集体过期）不同，击穿是“单点爆破”，只针对一个热点 key，但并发越高，冲击越猛。

典型场景：秒杀商品详情页、热搜榜单顶部条目、活动倒计时配置。这些 key 读多写少、访问集中，一旦过期策略没兜住，立刻见真章。

用 Redis 的 SET 命令加原子性续期，别依赖过期时间硬等

很多人习惯设个 EX 60 就完事，结果一到第 60 秒，所有线程都卡在 GET 返回空，再一起 DB 查询 + SET ——这就是击穿温床。真正靠谱的做法，是在业务逻辑里主动控制“谁来重建缓存”：

• 用 SET key value EX 60 NX 尝试争抢锁：只有第一个成功执行的线程能写入，其余线程等待或降级读旧值/空值
• 抢到锁的线程查 DB、组装数据、再 SET 回 Redis；没抢到的线程可走本地缓存、默认值，或最多等 100ms 后重试一次 GET
• 关键点：NX 保证原子性，EX 防止锁永远不释放，且不要用 DEL + SET 模拟锁——中间有竞态窗口

示例伪代码（Python）：

if redis.set("item:123", "", ex=60, nx=True):  # 抢到锁<br>    data = db.query("SELECT * FROM items WHERE id=123")<br>    redis.set("item:123", json.dumps(data), ex=60)<br>else:<br>    # 等待或返回兜底数据<br>    time.sleep(0.05)<br>    result = redis.get("item:123") or {"name": "暂无数据"}

本地缓存 + 逻辑过期，双保险绕开 Redis 过期机制

纯靠 Redis 锁还是有延迟和网络开销。更稳的做法是把“是否过期”的判断逻辑下沉到应用层：缓存值里塞一个 expire_time 字段，Redis 自身不设 TTL，由代码判断是否该刷新。

• 写缓存时：{"data": {...}, "expire_time": 1717028400}，用 SET item:123 存，不带 EX
• 读缓存时：GET 出来后解析 expire_time，若已过期，启动异步刷新任务（不阻塞当前响应），并返回旧值
• 优势：完全规避 Redis 过期事件的集中触发；缺点：需要应用层统一处理序列化/反序列化，且要防异步任务堆积

注意：别用 redis.expire() 动态改 TTL ——高并发下多次调用会相互覆盖，导致实际过期时间不可控。

布隆过滤器挡穿透，但对击穿基本没用

这点容易混淆：BloomFilter 是用来快速判断“这个 key 绝对不存在”，从而拦截缓存穿透的。但它对击穿无效——击穿的前提是 key 存在、只是刚好过期了。你用 BloomFilter 查 item:123，它大概率返回 true（存在），然后你照样 GET 到空，该击穿还是击穿。

所以别指望靠加一层过滤器解决击穿。真正要做的，是把“重建缓存”的动作变成受控、串行、带兜底的流程，而不是寄希望于不让请求进来。

最常被忽略的一点：很多团队加了分布式锁，却忘了设置合理的锁超时（比 DB 查询耗时长 2–3 倍即可），结果锁卡死、线程假死、后续所有请求全堵住——这比击穿还糟。