Redis Lua脚本无法直接获取CPU、内存等负载信息，需由外部监控系统将降级开关写入专用key，Lua脚本通过GET该key实现原子化条件执行，并支持兜底数据与evalsha安全更新。
Redis Lua脚本里怎么拿到当前负载信息
Redis 本身不暴露 CPU、内存或连接数等运行时负载指标给 Lua 脚本——redis.call() 能调用的命令里没有 INFO、CONFIG GET 或 MEMORY USAGE 这类查询接口。Lua 沙箱被严格限制，这是设计使然，不是遗漏。
所以「根据负载状态降级」必须绕开「在脚本里实时读负载」这条路。常见做法是：
- 由外部监控系统（如 Prometheus + Redis Exporter）持续采集
redis_server_cpu_sys_seconds_total、used_memory_rss、connected_clients等指标 - 将关键阈值判断结果（例如
is_overloaded = true）通过一个专用 key（如redis:health:overload_flag）写入 Redis，TTL 设为 10–30 秒，避免陈旧状态 - Lua 脚本中用
redis.call("GET", "redis:health:overload_flag")快速查这个开关，决定是否跳过耗时逻辑
用 EVAL 做条件执行时，如何避免原子性被破坏
很多人想在 Lua 里先 GET 降级开关，再根据结果决定是否 HGETALL 或 ZRANGE。这本身没问题，但要注意：一旦你把「降级逻辑」拆成多个 EVAL 调用（比如先查 flag，再根据结果发另一个 EVAL），就失去了原子性，也失去了 Lua 的核心价值。
正确姿势是把整个决策+执行封装在一个 EVAL 脚本里：
if redis.call("GET", KEYS[1]) == "1" then
return {["status"] = "degraded", ["data"] = {}}
else
return {["status"] = "ok", ["data"] = redis.call("HGETALL", KEYS[2])}
end
这样即使中间 flag 状态翻转，也不会出现「查到未过载、但执行时已过载」的错乱。注意：KEYS[1] 和 KEYS[2] 必须都传入，否则 EVAL 会报 ERR Error running script (call to f_...): @user_script:1: @enable_strict_redis_enabled@ 错误。
降级返回空数据 vs 返回缓存兜底数据，该怎么选
不是所有场景都适合直接返回空。比如用户中心接口，降级后返回空 profile 会导致前端渲染异常；而商品详情页降级返回 5 分钟前的 cache:product:123 快照反而更稳。
Lua 中做兜底要满足两个前提：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 兜底数据必须存在 Redis 中（不能从本地变量拼凑，那会破坏一致性）
- 兜底 key 需和主 key 有明确映射关系，例如主 key 是
user:456，兜底 key 可设为user:456:stale，且写入时带EX 300
示例片段：
local flag = redis.call("GET", KEYS[1])
if flag == "1" then
local stale = redis.call("GET", KEYS[2] .. ":stale")
if stale then
return cjson.decode(stale)
else
return {["status"] = "degraded", ["data"] = nil}
end
else
return redis.call("HGETALL", KEYS[2])
end
这里用了 cjson.decode，说明你存的是 JSON 字符串——别忘了提前用 redis.call("SET", key, cjson.encode(val), "EX", 300) 写入，否则 decode 会报错。
evalsha 复用脚本时，怎么安全更新降级策略
线上用 EVALSHA 而不是 EVAL 是为了性能，但策略更新时容易出问题：新脚本 SHA 和旧客户端缓存的不一致，导致 NOSCRIPT 错误，进而触发降级失败。
稳妥做法是双写+灰度：
- 先用
SCRIPT LOAD上传新脚本，拿到新sha - 在业务代码中，对关键调用点加一层 fallback：捕获
NOSCRIPT异常后，改用完整EVAL执行一次，同时打日志告警 - 逐步让所有客户端升级到新 SHA，确认无
NOSCRIPT报警后再清理旧脚本（用SCRIPT FLUSH）
别依赖 SCRIPT EXISTS 做判断——它只告诉你 SHA 是否存在，不保证客户端用的就是那个。
真正难的不是写几个 IF 判断，而是让「负载感知」这件事本身不成为新瓶颈。监控写 flag 的延迟、flag key 的过期抖动、以及 Lua 脚本里嵌套 GET 的额外开销，都得压在 0.5ms 内，否则降级就变成了添堵。
