Redis EVALSHA 找不到脚本时怎样恢复

Redis 的 EVALSHA 只拿 SHA1 摘要去执行服务端脚本缓存里的内容。遇到 NOSCRIPT No matching script 时，结论不是“脚本语法一定错了”，而是当前 Redis 实例找不到这个摘要对应的脚本。应用侧应保留脚本源，在确认是 NOSCRIPT 后用 SCRIPT LOAD 重新装载，或者用同一份源代码做一次 EVAL 回退，再按预算重试。

官方地址：https://redis.io/docs/latest/commands/evalsha/

下面只讨论脚本缓存缺失和回退加载。示例命令供读者在隔离测试实例中理解关系，不把示例输出当成已经在本机执行的结果。

先把 NOSCRIPT 当成缓存缺失

我排查这类错误时，先看错误前缀和调用目标，再看脚本本身。EVALSHA 的第一个参数是 SHA1 摘要，Redis 只有在当前实例缓存过完全对应的脚本时才能执行；摘要写错、连到了另一套实例、刚发生故障转移或脚本缓存被清理，都可能表现为找不到脚本。

SCRIPT EXISTS 可以查询一个或多个摘要是否存在。它适合诊断和预热，但不是并发调用中的可靠锁：检查之后缓存仍可能变化，应用仍需保留 NOSCRIPT 回退分支。

# 只查询摘要是否在当前 Redis 实例的脚本缓存中
redis-cli SCRIPT EXISTS 

# 输出 1 表示已识别，输出 0 表示当前缓存没有该摘要
# 这是诊断信号，不代替真正的 NOSCRIPT 兜底

让脚本源成为应用的一部分

缓存里的脚本不是持久化业务数据。Redis 官方文档明确说明，脚本缓存可能因实例重启、故障转移或 SCRIPT FLUSH 而丢失。因此只把 SHA1 写进配置、却没有在应用包中保留脚本正文，会让恢复动作失去输入。

推荐把脚本正文作为版本化资源，启动时可以预加载，但不要把“启动时加载成功”当成永久保证。连接到新主实例、发布新版本或发生切换后，第一次 EVALSHA 仍可能得到 NOSCRIPT，运行时回退必须存在。

# 用应用持有的同一份脚本源装载到当前实例；SCRIPT LOAD 只加载，不执行
script='return redis.call("INCRBY", KEYS[1], ARGV[1])'
sha=$(redis-cli --raw SCRIPT LOAD "$script")

# 使用 Redis 返回的摘要调用脚本，KEYS 数量必须与脚本约定一致
redis-cli EVALSHA "$sha" 1 demo:counter 1

这里最重要的是“同一份源代码”：如果应用以版本 A 计算摘要，却用版本 B 做回退，后续排查会变成两个问题叠在一起。脚本需要变更时，应让源代码、摘要和发布版本一起更新。

把回退动作限定在一次缺失处理内

运行时逻辑可以按下面的边界组织：先尝试 EVALSHA；只有错误明确以 NOSCRIPT 开头时，才使用保存的脚本源调用 EVAL，或先 SCRIPT LOAD 再按新返回的摘要重试。回退成功后，后续请求继续走摘要调用。

# 先走摘要路径，减少重复发送脚本正文
result=$(redis-cli --raw EVALSHA "$sha" 1 demo:counter 1 2>&1)
if printf '%s' "$result" | grep -q '^NOSCRIPT'; then
  # 只有确认缓存缺失才用源代码回退，其他错误原样交给上层
  result=$(redis-cli --raw EVAL "$script" 1 demo:counter 1)
fi

# 回退也失败时停止循环，避免把语法、权限或参数错误放大成重试风暴
printf '%s\n' "$result"

生产客户端通常会把这段逻辑封装在脚本对象中。关键是限制重试次数，避免每个请求都先执行一次 SCRIPT EXISTS；也不要捕获所有错误后统一当成 NOSCRIPT。若使用 SCRIPT LOAD 后重试 EVALSHA，应使用服务端返回的新摘要，而不是手工拼接摘要。

直接用 EVAL 回退更简单，但会重新发送脚本正文并触发脚本编译路径；如果回退频繁，通常说明实例切换、缓存清理或脚本版本管理存在问题，应把它做成可观测事件，而不是默默吞掉。

哪些错误不能继续重试

我会把恢复分成三类：明确的 NOSCRIPT 可以进行一次有界回退；脚本语法、参数数量、键类型或 ACL 错误应直接修复配置或代码；超时和连接断开则属于结果未知，不能因为“看起来像失败”就再次执行可能带写入副作用的脚本。

对于主从切换或代理后端变化，应用应该确保每次命令真正落到当前可写实例，并让脚本源随应用实例可用。脚本缓存缺失不是业务数据丢失，但回退操作依赖正确的路由、权限和参数，不能用一条无限重试循环掩盖这些前置问题。

常见问题

每次调用前都执行 SCRIPT EXISTS 可以避免 NOSCRIPT 吗？

不能完全避免。检查与执行之间仍可能发生实例切换或缓存变化，而且每次多一次往返。更实用的方式是保留脚本源，正常走 EVALSHA，遇到明确 NOSCRIPT 时一次回退。

可以只保存 SHA1，不保存 Lua 源码吗？

不建议。SHA1 只能标识脚本，不能在缓存丢失后恢复正文。应用发布包或脚本注册表至少要能取得与摘要对应的完整源代码。

回退成功后还要继续用 EVAL 吗？

通常不需要。回退成功后应恢复摘要路径；如果选择 SCRIPT LOAD，应保存服务器返回的摘要。持续大量 EVAL 会增加脚本正文传输和编译开销。

把 NOSCRIPT 当成“当前实例缺少脚本资产”的信号，恢复就会变得清楚：保存源代码，限制回退，区分真实错误，并把异常频率交给监控。这样既能应对重启和故障转移，也不会把权限、语法和结果未知问题误包装成缓存问题。