BUSY 错误是什么
Lua 脚本运行时间超过 lua-time-limit（默认 5000 毫秒，新版配置名也叫 busy-reply-threshold）之后，其他客户端再发命令会收到 BUSY 错误，实例表面上不可用。此时可以用 SCRIPT KILL 终止一个还没写过数据的脚本；如果脚本已经执行过写操作，强制终止会破坏数据一致性，只能评估后按预案处置。
基本信息
| 阈值配置 | lua-time-limit，默认 5000 毫秒 |
|---|---|
| 表现 | 其他客户端收到 BUSY 错误，普通命令被推迟 |
| 只读脚本 | 可以用 SCRIPT KILL 终止 |
| 已写脚本 | 无法安全终止，只能等待结束或按预案重启 |
| 相关命令 | SCRIPT LOAD、SCRIPT EXISTS、SCRIPT FLUSH、FUNCTION 系列 |
典型使用场景
- 脚本卡死处置：第一时间判断脚本是否已写过数据
- 脚本评审：上线前检查循环边界与处理的数据量
- 阈值调整：按业务可接受的中断时长设定
- 函数化改造：把常用脚本迁到 FUNCTION 统一管理与复用
- 预案演练：把终止与重启流程提前演练一遍
- 监控接入：脚本耗时与相关错误计数进入告警
查看与处置
查看与处置
redis-cli CONFIG GET lua-time-limit # 查看脚本超时阈值
redis-cli SCRIPT KILL # 终止尚未写过数据的脚本
redis-cli SCRIPT EXISTS <sha1> # 检查脚本是否已加载
redis-cli SCRIPT LOAD "return 1" # 预加载脚本，之后按 sha1 调用
redis-cli INFO memory | grep -E 'used_memory_lua' # 脚本引擎的内存占用
redis-cli INFO stats | grep -E 'total_error_replies' # 错误回复计数，侧面观察异常
redis-cli CLIENT LIST | grep -c 'cmd=eval' # 有哪些连接卡在脚本调用上处置对照
| 脚本状态 | 可用手段 | 后果 |
|---|---|---|
| 只读脚本超时 | SCRIPT KILL | 脚本终止，实例恢复服务 |
| 已执行写操作 | 无法安全终止 | 只能等待结束或按预案重启 |
| 脚本反复超时 | 下线脚本并修逻辑 | 需要客户端配合改造与回归 |
| 脚本占用内存过高 | 检查脚本复杂度与数据量 | 避免在大集合上做整体运算 |
BUSY 期间实例对普通命令几乎完全不可用，影响面按秒计算，脚本评审的价值远高于事后处置。
对已写过数据的脚本执行 SCRIPT KILL 会失败，此时强行重启可能造成数据不一致，处置前先确认持久化状态与可回滚的时间点。