Redis防击穿技巧与实战方法

缓存击穿是微服务场景下极具破坏性的性能隐患——当热点key过期瞬间，多个服务实例并发回源直击数据库，导致DB瞬时压力飙升甚至崩溃；本文直击本质，给出三重实战防护：用原子SET命令实现安全互斥锁防并发回源、以“逻辑过期”替代永不过期兼顾一致性与高可用、由业务服务自治维护强同步的布隆过滤器精准拦截无效请求，并强调真正决定成败的不是技术细节，而是团队间对缓存生命周期协同管理的清晰契约与可落地的更新SOP。

缓存击穿是什么，为什么在微服务里特别要命

缓存击穿指的是某个热点 key 过期瞬间，大量请求同时穿透 Redis 直击数据库，造成 DB 瞬时压力飙升。微服务环境下更危险：多个服务实例可能同时发现缓存失效，各自发起回源请求，相当于把单点 DB 压力放大 N 倍。

常见错误现象：MySQL CPU 突然拉到 100%、Redis hit rate 骤降、监控里看到某 key 的 get 请求量没变，但 DB select 暴增——基本就是击穿了。

用互斥锁（Mutex Lock）控制回源，别用 setnx 硬刚

最直接的解法是让第一个请求去查 DB 并写回缓存，其余请求等它完成。但很多人直接用 SETNX + EXPIRE 两步走，结果在并发下出现锁失效或过期时间丢失。

实操建议：

• 用 SET key value EX seconds NX 原子命令加锁，不要分两步；
• 锁的过期时间必须明显短于业务数据真实 TTL（比如数据缓存 5 分钟，锁设 30 秒），防死锁；
• 拿到锁的线程查 DB 后，写缓存前先校验锁是否还有效（可用 GET 检查值是否匹配）；
• 释放锁必须用 Lua 脚本，避免 DEL 误删别人持有的锁 —— 示例：

  if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("DEL", KEYS[1]) else return 0 end

提前续期 or 永不过期？选错策略反而加重问题

有人觉得“干脆不设过期时间”，或者用后台定时任务刷新热点 key，这在微服务里容易翻车。

原因很实在：

• 永不过期 → 数据一致性失控，上游服务改了数据，下游永远读旧值；
• 后台续期 → 多个服务实例都起定时任务，重复刷同一个 key，浪费资源还可能因执行时间漂移导致空窗；
• 真正稳妥的做法是：给热点 key 加一个“逻辑过期”字段，比如缓存值里塞个 expireAt 时间戳，应用层判断是否过期，再决定是否加锁回源；
• 这个方案兼顾一致性与可用性，但要求所有读该 key 的服务都遵循同一套解析逻辑 —— 微服务间契约得写清楚。

布隆过滤器兜底，但别在网关层硬上

布隆过滤器能快速拦截“根本不存在的 key”，防止恶意穿透或脏请求打穿缓存。但它不是银弹，尤其在微服务架构下容易用错。

关键点：

• 布隆过滤器必须和业务数据更新强同步，否则删了数据但过滤器没更新，会把真实请求也拦掉；
• 别在 API 网关统一加 —— 网关不知道各服务的数据语义，user:123 对用户服务存在，对订单服务就是无效 key；
• 应该由具体服务自己维护，比如用户服务在删掉 user:123 时，同步调用 BloomFilter.delete("user:123")；
• 内存占用和误判率得权衡：expectedInsertions=100w、fpp=0.01 是较常见的起步配置，别盲目调低 fpp 导致内存翻倍。

击穿的本质不是 Redis 不够快，而是多个服务对同一个缓存生命周期缺乏协同意识。最容易被忽略的，其实是那个没人愿意写的“缓存更新 SOP”文档 —— 键怎么命名、谁负责刷新、过期时间谁定、异常时怎么降级，这些细节比锁怎么写更重要。

今天关于《Redis防击穿技巧与实战方法》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！