用 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 拥有线稿上色优化、图片重绘、人物姿势检测、涂鸦完善等功能