强制终止Redis死循环Lua脚本技巧

Redis为保障Lua脚本执行的原子性，一旦脚本执行了任何写命令（如SET、DEL），便会进入不可终止（UNKILLABLE）状态，此时SCRIPT KILL将失效；面对由此引发的死循环卡顿，唯一有效手段是强制终止进程（如SHUTDOWN NOSAVE或kill -9），但会丢失未持久化数据；因此，真正关键的不是事后“怎么杀”，而是事前预防——严格限制脚本运行时长（lua-time-limit）、在所有循环中设置明确退出条件、避免无界循环与类型误判，并通过本地日志和参数校验提前暴露隐患，毕竟Redis宁可让脚本跑完也不接受半途而废的数据不一致风险。

SCRIPT KILL 为什么有时不生效？

直接结论：SCRIPT KILL 只能终止「尚未执行任何写命令」的脚本；一旦脚本调用了 redis.call('set', ...)、redis.call('del', ...) 等修改数据的命令，它就变成 UNKILLABLE —— 这不是 bug，是 Redis 为保障原子性做的硬性限制。

• 现象：执行 SCRIPT KILL 后返回 (error) UNKILLABLE Sorry the script already executed write commands...
• 原因：Redis 要求 Lua 脚本“全有或全无”，中途杀掉可能留下半写状态（比如库存扣了一半、订单建了没发券），这比挂起更危险
• 验证方法：用 redis-cli --stat 或监控 instantaneous_ops_per_sec，若持续为 0 且客户端卡住，大概率已进入不可杀状态

死循环脚本卡住后，还能做什么？

当 SCRIPT KILL 失效，你只剩两个真实可行的选项，没有中间路线：

• SHUTDOWN NOSAVE：最常用也最激进。它会立即终止 Redis 进程，且不触发 RDB/AOF 持久化，意味着上一次快照之后的所有写入全部丢失
• 重启进程（非优雅）：比如 kill -9 ，效果等同于 SHUTDOWN NOSAVE，但绕过了 Redis 自身的清理逻辑，风险略高
• 等待脚本自然结束？别信——只要循环里没 break 或超时检查，它就不会停；而 Redis 不会主动中断已写入的脚本

怎么避免下次再被死循环拖垮？

预防远比抢救重要。关键不是“怎么杀”，而是“不让它活过 5 秒”：

• 务必检查 lua-time-limit 配置（单位毫秒），默认 5000，可在 redis.conf 中调低（如 2000），改完需 CONFIG REWRITE 或重启
• 所有循环必须带退出兜底：用计数器 + if i > MAX_LOOP then break end，别依赖外部条件（比如 while redis.call('get', 'flag') == '1' 可能永远等不到）
• 本地调试时加 redis.log(redis.LOG_WARNING, 'loop step '..i)，上线前删掉——日志本身不耗时，但能快速定位卡点
• 禁止在脚本中使用 while true do 或无界 for，这是生产环境红线

EVAL 时传参不当也会伪装成死循环

看起来像卡死，其实只是参数类型错导致逻辑失效，比如：

• ARGV[1] 是字符串 "10"，但脚本里写了 if ARGV[1] > 5 then ... —— Lua 会做字符串比较，"10" > "5" 为 false，可能意外跳过 break 条件
• 正确写法是显式转数字：local limit = tonumber(ARGV[1]) or 0
• KEYS 和 ARGV 下标从 1 开始，但新手常写成 KEYS[0] 导致 nil，后续操作失败却无报错，循环空转

Redis 的原子性担保很可靠，但代价是：它拒绝“部分成功”。所以真正要盯紧的，从来不是 kill 命令怎么用，而是脚本里那几行循环有没有真正的出口。

本篇关于《强制终止Redis死循环Lua脚本技巧》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于数据库的相关知识，请关注golang学习网公众号！