缓存击穿的本质是热点key过期瞬间大量请求穿透缓存直打DB，因key存在但已过期且无互斥锁保护重建逻辑；Lua脚本通过原子性执行“判断+加锁+返回状态”解决该问题。
缓存击穿的本质是什么？
缓存击穿指的是某个热点 key 过期瞬间，大量请求同时穿透缓存直打 DB，造成数据库压力陡增。关键点在于：key 存在但已过期，且无互斥锁保护重建逻辑。Lua 脚本能解决这个问题，是因为 Redis 对单个 Lua 脚本的执行是原子的——只要脚本能覆盖「查缓存→发现过期→加锁→重建→写回」整个流程，就能避免并发重建。
GET + SETNX 组合为什么不够？
单纯用 GET 判断再用 SETNX 加锁，中间存在竞态窗口：两个客户端几乎同时 GET 到 nil，都尝试 SETNX，其中一个成功，另一个失败后仍可能直接去查 DB（没等锁释放或没重试）。Lua 脚本必须把「判断+加锁+返回状态」三步压进一次原子执行。
- 不要在 Lua 里调用外部命令（比如
redis.call("GET", KEYS[1])后再用if分支决定是否SETNX）——这本身不原子，因为 Lua 执行完后控制权就交还给客户端了 - 正确做法是：用
EXISTS或TTL检查 key 状态，再用SET带nx和ex参数一次性完成加锁 - 锁的 value 必须唯一（比如用 client ID 或随机 UUID），否则释放时无法区分所有权
一个可用的防击穿 Lua 脚本长什么样？
这个脚本接收 KEYS[1]（缓存 key）、ARGV[1]（锁过期时间，单位秒）、ARGV[2]（唯一锁标识）三个参数，返回三种状态：1 表示命中缓存，0 表示需重建（已成功加锁），-1 表示正在被其他客户端重建（需等待后重试）：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
local key = KEYS[1]
local lockExpire = tonumber(ARGV[1])
local lockValue = ARGV[2]
<p>local cacheVal = redis.call("GET", key)
if cacheVal ~= false then
return 1
end</p><p>local ttl = redis.call("TTL", key)
if ttl == -2 then -- key 不存在
if redis.call("SET", key .. ":lock", lockValue, "NX", "EX", lockExpire) == "OK" then
return 0
else
return -1
end
elseif ttl == -1 then -- key 存在但永不过期（异常情况）
return 1
else -- key 存在但已过期（ttl > 0 表示剩余秒数，过期后 TTL 返回 -2）
return 1
end注意：TTL 返回 -2 表示 key 不存在，-1 表示存在但无过期时间；而 key 过期后，GET 返回 false，TTL 也返回 -2。所以仅靠 GET 无法区分「从未写入」和「刚过期」，必须结合 TTL 判断。
客户端怎么配合这个脚本？
脚本只负责“决策”，不负责“重建”。客户端收到 0 就去查 DB、生成新值、写回缓存并删锁；收到 -1 就 sleep 后重试（建议用指数退避）；收到 1 直接返回缓存值。容易漏掉的点：
- 锁释放必须用 Lua 脚本校验 value 再
DEL，不能简单DEL key:lock，否则可能误删别人持有的锁 -
SET锁时的EX时间要明显大于 DB 查询+写缓存耗时，否则锁自动释放后多个客户端又会同时重建 - 如果业务允许，更轻量的做法是用
GETSET配合空值缓存（写入"null"并设较短过期），但对严格一致性场景不适用
真正难的不是写脚本，而是锁超时时间估算、重建失败后的兜底策略、以及空值缓存与真实 null 的区分——这些都得贴着业务来调。
