如何根据Redis负载状态，在Lua脚本中实现Redis的优雅降级策略？

本文共计1121个文字，预计阅读时间需要5分钟。

Redis 本身不直接暴露 CPU、内存或连接数等运行时负载指标。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 中（不能从本地变量拼凑，那会破坏一致性）
• 兜底 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 内，否则降级就变成了添堵。