Redis淘汰机制下缓存击穿更危险，因热点key可能被LRU提前驱逐，引发大量请求并发打穿数据库；需用SET key value EX seconds NX原子加锁、UUID防误删、Lua校验释放，并控制重试与空值缓存。
缓存击穿在Redis淘汰机制下为什么更危险
Redis启用 maxmemory + volatile-lru（或 allkeys-lru 等）后，热点 key 可能因内存压力被提前驱逐，而此时若大量请求同时发现缓存 miss，就会一股脑打到数据库——这不是冷启动时的“缓存雪崩”，而是单个 key 被踢出后引发的“击穿”。尤其当该 key 对应的是高并发、低频更新的业务数据（如商品详情、活动配置），问题会立刻暴露。
用 SETNX + 过期时间实现轻量互斥锁
不能依赖 Redis 自带的 EXPIRE 单独设过期，因为 key 不存在时多个线程会同时执行 SETNX 失败重试逻辑。必须把“加锁”和“设置过期”合并为原子操作，否则会出现锁不释放或永远无法获取的问题。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
SET key value EX seconds NX是唯一安全起点：它同时完成“不存在才设值”+“自动过期”，避免先SETNX再EXPIRE的竞态 - value 必须是全局唯一标识（如 UUID 或服务实例+线程ID拼接），防止误删他人持有的锁
- 锁过期时间建议略大于 DB 查询+写入缓存的 P99 耗时（例如 DB 查询平均 80ms，P99 200ms，则设
EX 300） - 释放锁必须用 Lua 脚本校验 value 一致性：
if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("DEL", KEYS[1]) else return 0 end
应用层代码中怎么嵌入锁逻辑（以 Go 为例）
不是所有 miss 都要上锁。只有确认是“已知热点 key”且当前无缓存时，才走锁流程；否则直接查 DB 返回，避免锁开销污染普通路径。
- 先
GET缓存，命中则直接返回 - 未命中时，用
SET key lock_value EX 300 NX尝试加锁；返回1表示抢到锁，进入回源流程 - 返回
0表示锁已被占，此时应短暂time.Sleep(5 * time.Millisecond)后重试GET（最多 3 次），而非无限等待——防止锁持有者异常崩溃导致死等 - 抢到锁的协程查 DB 成功后，必须用 Lua 脚本释放锁，并立即
SET新缓存（带正常业务过期时间，比如EX 3600） - DB 查询失败时，仍要释放锁，但可写一个空值缓存（
SET key "null" EX 60）防穿透，注意 value 不能是纯null字符串，需约定协议如{"code": -1, "msg": "not_found"}
容易被忽略的三个细节
很多人写了锁逻辑却还是击穿，问题常出在边界没控住：
- Redis 客户端连接池耗尽时，
SET命令超时失败，但业务代码没判断返回值，直接走查 DB 路径——等于锁形同虚设。必须检查SET返回是否为OK或1 - DB 回源成功后写缓存前发生 panic（比如 JSON 序列化失败），锁释放了，但缓存没写成，下次请求又进锁流程。建议把“写缓存”作为锁内最后一步，并用 defer 保障
- 使用
allkeys-lru时，哪怕设置了永不过期的 key，也可能被驱逐。所以即使业务上认为“这个 key 绝对不该被淘汰”，也要在应用层保留完整的锁+回源逻辑，不能省略
