Redis主从复制导致的CPU高负载_检查从库是否开启了昂贵的Lua脚本-Redis-PHP中文网

Redis从库CPU飙升时，优先检查lua-time-limit是否被突破；因脚本超时触发强制中断与重试循环，导致CPU持续飙高，日志可见“Timeout while executing script”等提示。

redis主从复制导致的cpu高负载_检查从库是否开启了昂贵的lua脚本

从库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，别急着优化脚本，先确认它是否本就不该出现在从库执行路径里。