Redis如何防止热点Key过期引发缓存击穿

用 SETNX 加分布式锁是最直接的解法：通过原子性设置带业务前缀和过期时间的锁（如 lock:product:10086），配合 Lua 脚本安全释放，可有效防止缓存击穿导致的数据库雪崩。用 SETNX 加分布式锁是最直接的解法缓存击穿本质是：一个热门 key 过期瞬间，大量请求同时穿透到数据库。不加控制的话，DB 就会收到几百上千次重复查询——哪怕只持续 1 秒，也足以拖垮服务。用 SETNX（即 SET if Not eXists）在 Redis 里设一个临时锁是最常用、最轻量的方案。它天然支持原子性，且不需要额外组件。锁名建议带业务前缀和 key，比如 lock:product:10086，避免不同业务误删必须设置过期时间（EX 参数），否则锁进程崩溃或异常退出会导致死锁锁超时时间要略大于 DB 查询 + 写缓存的耗时，但别设太长（如超过 5 秒），否则等待线程积压严重释放锁不能简单 DEL，得用 Lua 脚本保证“判断+删除”原子性，否则可能删掉别人刚加的锁逻辑过期比物理过期更抗压，但要注意脏数据窗口不设 EX，改在 value 里存一个逻辑过期时间戳，是另一种主流思路。它把“是否过期”的判断从 Redis 移到应用层，彻底避开物理过期那一瞬的并发洪峰。但它不是银弹：新值还没刷进缓存前，所有请求拿到的都是旧数据。对价格、库存等强一致性场景不适用，但对商品描述、用户资料这类容忍延迟的场景很友好。更新缓存必须加锁（仍用 SETNX），否则多个线程可能同时触发 DB 查询异步刷新推荐走线程池或消息队列，别用 Thread.start()，避免线程爆炸返回旧值时，要确保这个旧值本身没被其他逻辑误删或覆盖监控逻辑过期 key 的刷新耗时，如果某次 DB 查询卡住，会导致后续所有请求都返回陈旧数据预热 + 随机 TTL 是预防型手段，适合已知热点如果能提前知道哪些是热点（比如首页 banner、秒杀商品、排行榜前 20），就别等它过期再救火，主动预热更稳。 稿定AI 拥有线稿上色优化、图片重绘、人物姿势检测、涂鸦完善等功能