缓存击穿是热点key过期瞬间大量请求穿透至数据库，单靠setnx无法解决因“判断+写入”非原子导致的竞态问题；需用lua脚本实现原子性检查，结合客户端回源与nx写入保障一致性。
缓存击穿到底是什么，为什么单靠 SETNX 不够
缓存击穿指某个热点 key 过期瞬间，大量并发请求同时发现缓存缺失，全部穿透到数据库，造成瞬时压力激增。单纯用 SETNX 判断是否存在再 set，存在竞态：多个请求几乎同时 SETNX 失败（因为还没来得及写入），又同时去查 DB，结果还是打穿了。
根本问题在于「判断缓存是否存在」和「写入新缓存」这两步不是原子的。哪怕加锁（如 Redis 分布式锁），锁的获取、业务查询、缓存写入整个链路长，锁持有时间不可控，还可能因异常导致锁未释放。
解决思路很直接：把「检查 + 设置 + 回源逻辑」收束进一次 Redis 操作里——这就轮到 Lua 脚本上场了。
Lua 脚本如何用一个命令完成“查缓存、无则查库并回填”
Redis 执行 Lua 脚本是原子的：脚本内所有 Redis 命令按顺序执行，期间不会有其他客户端命令插入。我们可以把「GET → 为空则调用本地逻辑查 DB → SET」这整条链路中「依赖 Redis 状态」的部分全塞进脚本，而把真正查 DB 的动作留在客户端做。
典型做法是两阶段：
- 先在 Lua 脚本里用
redis.call("GET", KEYS[1])尝试取值 - 如果返回
nil，脚本返回一个特殊标记（比如"MISS"），告诉客户端：“你去查 DB 吧” - 客户端收到
"MISS"后查 DB，拿到结果后，**再用另一个 Lua 脚本**（或带条件的SET ... NX EX）尝试写入缓存 —— 注意这里必须用NX防止多个客户端同时写入覆盖
关键点：第一阶段只读不写，第二阶段写入带 NX 保护。这样既避免了长事务，又保证了只有一个客户端能成功回填缓存。
为什么不用 EVAL 直接在 Lua 里查 DB
不能。Lua 脚本运行在 Redis 服务端，它没有网络能力，无法发起 HTTP 请求或连接 MySQL。所谓“在 Lua 里查库”是常见误解。所有外部 I/O 必须由客户端完成。
有人试图用 redis.call("EVAL", ...) 嵌套执行另一个脚本，这也不行——Redis 禁止在 Lua 中递归调用 EVAL 或 EVALSHA，会报错 ERR recursive script detected。
所以实际结构只能是：EVAL（查缓存）→ 客户端分支处理 → 条件性 SET 或 EVAL（写缓存）。中间那一步“查 DB”，永远在应用进程里做。
真实部署时最容易被忽略的三个细节
一是脚本 SHA1 缓存没复用：EVALSHA 比 EVAL 快，但必须先用 SCRIPT LOAD 注册，否则 EVALSHA 会失败并退化成 EVAL。上线前漏掉 SCRIPT LOAD，等于白优化。
二是 key 过期时间硬编码在脚本里：比如脚本里写死 redis.call("SET", KEYS[1], ARGV[1], "EX", 3600)。一旦要调整 TTL，就得改脚本、重 LOAD、清旧 SHA —— 不如把过期时间作为 ARGV[2] 传入，脚本更灵活。
三是没处理 Lua 返回值类型：Redis Lua 中 nil 和空字符串 "" 不等价，redis.call("GET", ...) 找不到 key 返回的是 nil，但如果你在脚本里写了 if res == "" then，永远进不去分支。正确写法是 if not res then 或 if res == false or res == nil then。
