缓存击穿核心是热点key过期或清理后，大量请求瞬时穿透至数据库；解决方案包括互斥锁（setnx控制唯一重建）、逻辑过期（value内嵌expireat+异步刷新）、提前预热、二级缓存及熔断降级。
高并发下缓存击穿的核心是：单个热点 Key 过期或被清理后，大量请求同时穿透到数据库，造成瞬时压力峰值。关键不在于“要不要重建”，而在于“谁来重建、何时重建、怎么避免重复重建”。
用互斥锁控制重建入口
只允许一个请求去查库并写缓存，其余请求等待或稍作重试。
- 用 Redis SETNX（setIfAbsent） 获取分布式锁，key 命名为
lock:goods:1001，设置 10 秒自动过期防止死锁 - 拿到锁的线程查询数据库，成功后写入缓存并主动释放锁
- 没拿到锁的线程可选择 短暂休眠 + 重试（如 50ms 后再查一次缓存），避免长等待
- 注意：锁粒度要细，按业务主键隔离，不能全局一把锁
给热点数据加逻辑过期时间
物理上不设 TTL，但 value 内部携带一个“逻辑过期时间戳”，由后台异步刷新保障可用性。
- 写缓存时，value 封装为
{"data": {...}, "expireAt": 1754523600000} - 读取时先判断
expireAt ，若已逻辑过期，则触发异步刷新任务（不影响当前返回） - 异步线程用 Redis 锁确保只有一个在更新，失败时记录告警，不阻塞主线程
- 适合对实时性要求不高、但可用性极高的场景，比如首页推荐、活动 banner
提前续期 + 主动预热
不让过期发生在请求高峰时刻，而是把重建动作前置化、平滑化。
- 在热点 Key 原有过期时间前 2～5 分钟，由定时任务或监听机制触发 异步刷新
- 秒杀类场景可结合业务节奏预热：活动开始前 10 分钟批量加载商品、库存、规则等热点数据
- 配合本地缓存（如 Caffeine）做二级兜底，即使 Redis 瞬间抖动，JVM 内存里仍有短时效副本
- 监控 key 的
ttl和freq，发现临近过期且访问频次突增，自动触发保护动作
兜底限流与快速失败
当重建过程出现异常（如 DB 查询超时、锁竞争激烈），要有降级路径。
- 对重建中的 key，设置 短时熔断窗口（如 1 秒内最多允许 1 次重建尝试）
- 若连续失败 N 次，临时返回缓存旧值 + 标记 “stale=true”，前端可灰度提示“数据可能略有延迟”
- 核心接口加 QPS 限流（如 Sentinel 或网关层），防止单个击穿引发雪崩式连锁反应
