Redis怎样优化大量Lua并发调用带来的CPU压力

EVAL并发高导致Redis CPU突增是因为其单线程执行Lua脚本大量请求串行等待而非算力瓶颈常见表现为CPU使用率高但延迟不明显、evicted_keys上升根本原因包括全量KEYS扫描、未预热EVALSHA、大结果返回及纯计算循环。为什么 EVAL 并发高会导致 Redis CPU 突增Redis 是单线程执行 Lua 脚本的EVAL 和 EVALSHA 都会阻塞主线程直到脚本跑完。哪怕脚本只耗时几毫秒100 个并发进来就等于排队等 100 × 几毫秒——CPU 不是被算力压垮的是被「串行等待」拖满的。常见现象INFO cpu 里 used_cpu_sys 或 used_cpu_user 持续 80%但 redis-cli --latency 显示延迟不高监控看到 instantaneous_ops_per_sec 没爆但 evicted_keys 或 expired_keys 反而上升说明其他命令在排队。脚本里用了 for 循环遍历大集合比如 redis.call(KEYS, user:*)——这比单纯多请求更伤用 EVAL 发送重复脚本没预热 EVALSHA每次都要重解析额外消耗 CPU脚本返回超大结果如 return redis.call(LRANGE, list:100k, 0, -1)序列化网络拷贝也占 CPU怎样让 EVALSHA 真正生效而不是假装优化EVALSHA 本身不省计算只省解析。但很多人漏掉关键两步预加载 容错 fallback结果线上还是走 EVAL 白忙活。启动时用 SCRIPT LOAD 提前加载脚本拿到 sha1 值缓存到应用层别每次运行时现场 SCRIPT LOAD调用 EVALSHA 后必须检查返回是否为 NOAUTH 或 NOSCRIPT 错误遇到就自动 fallback 到 EVAL 并重新 SCRIPT LOAD集群模式下SCRIPT LOAD 必须发到对应 slot 的节点不能随便连一个 proxy 就 load —— 否则其他节点根本没这个 sha1示例伪代码sha cache.get(my_script_sha)brif not sha:br sha redis.eval(SCRIPT LOAD, script_content)br cache.set(my_script_sha, sha)brres redis.eval(EVALSHA, sha, keys, args)brif res NOSCRIPT:br # 重试逻辑不是直接 panic/br sha redis.eval(SCRIPT LOAD, script_content)br res redis.eval(EVALSHA, sha, keys, args)哪些 Lua 操作最该砍掉优先级最高不是所有脚本都适合留在 Redis 里。以下三类操作CPU 开销和风险远大于收益应第一时间移出 通义听悟 阿里云通义听悟是聚焦音视频内容的工作学习AI助手依托大模型帮助用户记录、整理和分析音视频内容体验用大模型做音视频笔记、整理会议记录。