直接在OpenResty的Lua层用Redis互斥锁可拦截90%以上缓存击穿请求，但需协同设计锁生命周期、重试逻辑和空值缓存；仅用redis.setnx易致锁残留、协程堆积，应改用redis.eval原子脚本实现带逻辑过期的加锁，并辅以本地旧数据返回、指数退避重试和空值独立缓存三大兜底措施。
直接在 OpenResty 的 Lua 层加 Redis 互斥锁，能拦住 90% 以上的击穿请求——但前提是锁的生命周期、重试逻辑和空值缓存必须协同设计，否则反而会放大超时或雪崩风险。
为什么不能只靠 redis.setnx 做锁？
OpenResty 中用 redis:setnx 尝试设锁看似简单，但实际运行中容易卡死或漏放：
-
setnx成功后若 Lua 脚本中途报错（比如数据库查询失败、JSON 序列化异常），redis:del不会被执行，锁永久残留 - 没有过期时间保护：OpenResty 进程崩溃、worker 被 kill 或网络中断都会导致锁无法释放
- 客户端重试无节制：未命中缓存的请求在等待锁释放期间，若不做退避或超时控制，可能堆积大量协程
用 redis.eval 原子写锁 + 逻辑过期更稳妥
推荐在 Lua 中调用 Redis 的 eval 执行一段原子脚本，同时完成「尝试加锁 + 检查逻辑过期时间 + 写入带时间戳的数据」三件事。示例 Lua 片段：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
local key = "shop:" .. ngx.var.id
local lock_key = "lock:" .. key
local ttl = 300 -- 缓存总有效期（秒）
local logic_expire = ngx.time() + 60 -- 逻辑过期提前 60 秒
<p>-- 原子操作：只有 key 不存在 或 已过逻辑期，才允许写入新数据并设锁
local script = [[
local cur = redis.call("GET", KEYS[1])
if not cur or tonumber(cjson.decode(cur).expire) < tonumber(ARGV[1]) then
redis.call("SET", KEYS[2], "1", "EX", ARGV[2])
return 1
end
return 0
]]
local ok = redis:eval(script, 2, key, lock_key, logic_expire, 10)关键点：
- 不依赖外部判断，避免「先 GET 再 SETNX」的竞态窗口
- 锁本身只存 10 秒（
ARGV[2]），远短于业务重建耗时，防死锁 - 数据体里嵌了
expire字段，读取时用cjson.decode提取并比对，决定是否触发重建
OpenResty 层必须补上的三个兜底动作
光有锁不够，接入层要主动分担压力，否则 Redis 还是会被打穿：
- 对已确认「逻辑过期」的 key，立即返回本地缓存副本（哪怕旧一点），而不是让所有请求排队等锁 —— 这就是「缓存可用性优先」的实际落地
- 用
ngx.sleep实现指数退避重试（如首次等 50ms，失败后等 100ms、200ms…），避免锁释放瞬间大量请求洪峰涌进 - 对空结果也缓存，但必须用独立 key（如
empty:shop:123）+ 短 TTL（30s），防止恶意刷不存在 ID 导致布隆过滤器未覆盖时直接穿透
真正难的不是写锁，而是判断什么时候该返回旧数据、什么时候该等、什么时候该拒掉——这些决策点藏在业务 SLA 和数据新鲜度要求里，没法套模板。比如商品价格更新容忍 2 秒延迟，但库存变更必须强一致，这两类 key 就得走完全不同的击穿防护路径。
