缓存击穿的本质是热点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</p>
注意: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 的区分——这些都得贴着业务来调。










