Redis从库CPU飙升时，优先检查lua-time-limit是否被突破；因脚本超时触发强制中断与重试循环，导致CPU持续飙高，日志可见“Timeout while executing script”等提示。
从库CPU飙升时，优先检查 lua-time-limit 是否被突破
Redis 从库（slave）在执行主库同步来的 Lua 脚本时，若脚本运行超时，会触发强制中断并记录警告，但这个过程本身会反复尝试、重试、加锁，极易引发 CPU 持续飙高。这不是脚本没执行完的问题，而是 Redis 内部的超时保护机制在“卡住”状态反复轮询。
关键判断依据是日志中是否出现：Timeout while executing script (script may be too slow) 或 Script attempted to access a non-existent key during replication —— 后者常伴随前者，说明脚本在从库回放阶段因 key 不存在而反复失败。
-
lua-time-limit默认是 5000 毫秒（5 秒），从库执行脚本时严格受此限制；主库不校验该值，只负责传播EVALSHA命令 - 从库执行 Lua 时无法访问写命令（如
redis.call('SET',...)）所依赖的 key，因为复制是单向异步流，脚本执行时刻 key 可能尚未到达 - 即使脚本本身逻辑简单，只要包含
redis.call()读取某个尚不存在的 key（尤其在首次全量同步后、增量还未追上时），就会触发超时+重试循环
用 CLIENT LIST 快速定位正在卡住的 Lua 执行客户端
在从库上直接运行：CLIENT LIST，过滤出 cmd=eval 或 cmd=evalsha 且 state=reading 或 state=busy 的连接 —— 这类连接极大概率就是卡在 Lua 脚本里了。
注意看 age（存活秒数）和 idle（空闲秒数）：如果 age 很大但 idle 很小（比如
- 搭配
CLIENT KILL ID <id></id>可临时杀掉可疑连接，观察 CPU 是否回落（仅用于验证，非根治） - 不要依赖
INFO replication查延迟，它只显示复制偏移差，不反映脚本阻塞 - 若
CLIENT LIST中大量连接显示cmd=multi+state=queue，可能是主库发来的大事务压住了从库指令队列，Lua 不一定是元凶，但常与之共存
禁止从库执行 Lua 的最简配置：设 lua-replicate-commands no 并重启
Redis 4.0+ 引入了 lua-replicate-commands 配置项，默认为 yes，表示主库把 Lua 脚本拆成原子命令再同步；设为 no 后，主库改用 EVAL / EVALSHA 原样传播，从库必须本地执行脚本 —— 这正是问题源头。所以反直觉地，**想让从库不执行 Lua，就得关掉它**。
真正起作用的是另一个隐式行为：当 lua-replicate-commands no 时，Redis 会拒绝在从库上执行任何 EVAL* 命令（返回 READONLY You can't write against a read only slave.），从而彻底规避脚本执行环节。
- 该配置必须在从库配置文件中设置，并重启生效；
CONFIG SET不支持热修改 - 主库保持
lua-replicate-commands yes（默认），确保命令能正确拆解同步 - 此方案要求所有 Lua 脚本都满足“无副作用”——即只读、不调用
redis.call('SET'...)等写操作，否则主库也无法安全拆解
更稳妥的做法：主库脚本加 redis.replicate_commands() 显式控制
如果你无法重启从库，或需要保留部分脚本写能力，就在 Lua 脚本开头显式调用 redis.replicate_commands()，强制主库将脚本展开为单条命令流下发，从库不再执行脚本，只执行还原后的命令序列。
这是比配置更细粒度的控制方式，但要求你有脚本修改权限，且脚本能被完全展开（不能含动态 key 构造、条件分支影响命令数量等）。
- 未加该调用的脚本，在
lua-replicate-commands yes下仍可能以EVALSHA形式传播，从库照常执行 → 风险仍在 - 加了之后，若脚本内有
redis.call('KEYS',...)这类不支持展开的命令，主库会直接报错ERR Lua redis() command contains unknown subcommand - 用
SCRIPT LOAD+EVALSHA组合时，务必确认脚本内容已更新，否则旧 SHA 对应的旧脚本可能没加replicate_commands
真正难排查的不是脚本慢，而是脚本在从库上“不该执行却执行了”，且执行环境（key 缺失、只读上下文）和主库不一致。一旦怀疑 Lua，别急着优化脚本，先确认它是否本就不该出现在从库执行路径里。
