缓存击穿是热点key过期瞬间大量请求直击数据库，微服务中因多实例并发回源使DB压力放大N倍；需用原子SET命令加锁、逻辑过期替代永不过期、服务自治布隆过滤器并强同步更新。
缓存击穿是什么，为什么在微服务里特别要命
缓存击穿指的是某个热点 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”文档 —— 键怎么命名、谁负责刷新、过期时间谁定、异常时怎么降级，这些细节比锁怎么写更重要。
