Redis Lua 长脚本卡住后怎么止损：-BUSY 告警、SCRIPT KILL 与原子性判断

线上接口突然集体变慢，翻遍慢日志却找不到哪条普通命令耗时特别高，最后在运维专属连接上查到的异常提示是 -BUSY Redis is busy running a script。这类问题基本不是 Redis 莫名其妙随机卡死，而是某段 Lua 脚本占住了服务端的单线程事件循环，后续发过来的客户端请求只能全部排队等它跑完。

先确认卡住的脚本有没有执行过写操作：纯读取的长耗时脚本可以尝试 SCRIPT KILL；一旦脚本已经产生写入动作，就不能靠强杀保住原子性，要么等脚本自然跑完，要么在明确能接受数据不一致风险的时候走进程级的恢复操作。

Redis 为什么会返回 -BUSY

Redis 执行 Lua 脚本时，会把脚本当成原子操作全程独占主线程。脚本没返回之前，其他客户端没法插入执行普通命令；这个设计保证了脚本的中间状态绝对不会被外部读到，但副作用也很明显：一段写死了无限循环的代码，或者一次性要扫完超大集合的脚本，会直接把整个实例的响应拖死。

lua-time-limit 是“脚本运行多长时间之后开始对外标记繁忙”的阈值，默认数值可以直接在实例配置里查到。它根本不是什么线程级的自动取消开关。超过这个阈值之后，Redis 只会给其他请求返回忙状态，允许管理员后续发 SCRIPT KILL 指令，但绝对不会主动把脚本从执行中途掐断。

现场排查先确认哪三件事

碰到问题先别急着去调大超时参数。先拿独立的管理级连接确认 Redis 还能响应诊断命令，再把当前的现象和脚本的实际运行状态对应上。

1. 从应用日志里提取最早出现 -BUSY 的时间、关联命令名和对应的调用业务方，先排除是客户端连接池自己耗尽导致的假故障。
2. 用 SLOWLOG GET 查看最近有没有异常的脚本调用记录；注意慢日志只会记录已经执行完成的命令，当前正在卡住的脚本不会出现在慢日志列表里。
3. 检查问题脚本有没有可能遍历无边界的集合、一次性访问海量 key，或者直接把客户端传进来的数量参数不加校验就当成循环的上限值。

CONFIG GET lua-time-limit
SLOWLOG GET 20
INFO commandstats

上面这几个诊断命令只能帮你确认超时阈值、历史慢命令和实例整体的热点情况，没法直接证明“当前正在跑的脚本一定是只读的”。真正的处置分界点，要看脚本实际已经执行过哪些操作。

SCRIPT KILL 什么时候可以用

如果脚本全程只做数据读取，或者到被发现的那一刻为止还没执行任何写操作，可以在另一个独立的管理连接里发送下面的指令：

SCRIPT KILL

执行成功时管理连接会收到 OK 的返回提示，正在等待脚本结果的业务客户端会直接拿到报错。这个操作不会把脚本执行中途的写入做回滚，它的适用前提本身就是脚本还没产生任何写入；非常适合处理误写的死循环、或者传了超大扫描范围的只读校验类脚本。

不少团队一看到 BUSY 报错就反复重试 SCRIPT KILL，这种操作完全没有效果。只要脚本已经修改过数据，Redis 会直接拒绝终止请求，因为中途杀掉脚本会彻底破坏 Lua 脚本的原子性保证。这时候应该先把脚本内容、入参和当前的业务影响范围记录下来，等脚本自然执行结束，后续再按预先定好的数据恢复方案做核对。

已经写入数据的脚本为什么不能强行停掉

假设脚本开头先执行了 SET order:1001 processing 写入操作，后面才开始遍历一个超大集合。这时候哪怕后半段逻辑还没跑完，外部客户端也绝对不能看到一个被拆分开的中间事务状态。直接杀掉 Redis 进程虽然能立刻停掉脚本，但很可能让持久化文件和主从同步的状态进入需要人工介入校验的异常局面，付出的代价比单次业务请求超时大得多。

怎么避免下一次再拖垮主线程

脚本设计阶段最有效的限制手段，根本不是把 lua-time-limit 阈值调得更大，而是保证单调用的绝对工作量有明确上限。大集合的批量处理改成游标分批模式，每批只处理固定数量的 key，把“扫完全部数据再统一写入”的大任务拆成多个可独立重试的小步骤。参数校验也要放在脚本逻辑的最开头，直接拒绝零值、负数还有明显超出业务合理上限的数量入参。

脚本上线之前，可以在数据规模和生产对齐的副本上做一次最坏参数场景的测试，记录下脚本的实际耗时、处理条目数和 P99 表现。线上侧至少要监控脚本耗时、-BUSY 错误数、Redis 主线程延迟和慢日志增长速率这几个核心指标，只有确认所有相关指标都回落到正常区间，才能判定故障完全恢复。

相关问题

lua-time-limit 阈值调大之后就不会发生阻塞了吗？

不会。这个参数改的只是 Redis 开始对外报告脚本运行过慢的阈值，既不会让脚本变成多线程并行执行，也不会解除单线程事件循环的独占阻塞特性。

脚本逻辑明明没有写入，但是执行 SCRIPT KILL 却返回报错该怎么排查？

先确认你用来发指令的管理连接连的是同一个实例对应相同的数据库节点，再回头检查脚本的实际执行路径里有没有触发写命令的分支。不要靠自己写代码时的业务意图判断脚本是不是“只读”，要以实际运行时的执行路径结果为准。

能不能靠客户端的超时机制自动重试脚本调用？

不能直接配置自动重试。客户端超时只代表客户端没等到服务端的回复，这时候服务端侧的脚本很可能还在正常运行；必须先确认实例上的脚本状态，再决定要不要重试，不然很可能把同一批业务操作重复提交两遍。

把故障处理收敛成一张清单

碰到 -BUSY 异常的时候，处理流程可以固定成标准化顺序：先记录故障发生时间和调用方信息，确认当前运行的脚本内容和对应的节点，判断脚本有没有执行过写入，确认是只读脚本之后再考虑执行 SCRIPT KILL，如果已经产生写入就走原子性保障和既定的恢复预案，最后补上参数校验上限和耗时告警的规则。这个顺序看起来比盲目重启慢半步，但能帮你避免搞丢整批业务状态的重大事故。