应用请求突然大量失败，Redis返回 BUSY Redis is busy running a script，说明某段Lua脚本或Redis Function执行时间已经超过脚本时间限制。Redis开始响应其他客户端，但普通命令会收到BUSY，服务并没有真正恢复可用。
能否安全终止，取决于脚本是否已经执行过写命令。 只读脚本可以尝试kill；已经写入的脚本不能中途终止，否则会破坏脚本原子性。
先确认是脚本阻塞而不是网络故障
从应用使用的同一端点执行轻量命令：
redis-cli -h 127.0.0.1 -p 6379 PING
redis-cli -h 127.0.0.1 -p 6379 INFO server处于BUSY状态时，PING也可能返回错误。保存完整错误、Redis版本、实例地址和开始时间，再查看服务日志：
sudo journalctl -u redis-server --since '20 minutes ago' --no-pager容器环境改用对应的容器日志。日志会提示脚本运行过久，并可能包含脚本SHA或调用线索。必须确认应用连接的真实节点，不能在另一台副本或默认6379端口上得出结论。
找到脚本来源和调用方
检查应用在故障时间附近的EVAL、EVALSHA、FCALL调用、任务队列和发布记录。Redis无法替你还原完整业务代码，脚本SHA需要与应用仓库或脚本注册表对应。
查看客户端连接：
redis-cli CLIENT LIST关注客户端名称、地址、连接时长和最近命令。输出可能包含内部IP、用户名或业务标识，分享前应脱敏。若应用未设置client name，建议后续通过连接参数命名，便于事件定位。
先锁定调用者，再停止该任务的继续重试。 否则刚解除BUSY，新请求又会提交同一段脚本，故障立即复现。
判断脚本是否已经写入数据
SCRIPT KILL 只会终止尚未执行写命令的脚本。Redis用这一限制保护脚本的原子语义；脚本一旦修改数据，中途终止会让其他客户端看到不完整状态。
检查脚本源代码中是否包含SET、HSET、DEL、INCR、ZADD等写命令，并结合业务日志判断运行路径。仅凭脚本设计为只读还不够，分支条件可能在故障请求中走到写路径。
对于Redis Functions，对应的管理命令和可终止条件需要按当前版本官方文档确认。没有代码和调用证据时，不要假设脚本是只读，也不要直接尝试破坏性恢复。
只读脚本可以尝试SCRIPT KILL
确认脚本没有执行写命令后，在同一实例执行：
redis-cli SCRIPT KILL成功后立即检查PING、应用错误率和日志：
redis-cli PING
redis-cli INFO stats
redis-cli SLOWLOG GET 20kill只解除当前执行，不会修复脚本算法。先保持问题任务暂停，在隔离环境复现并修改代码。若命令返回脚本已经写入数据而不能终止，应停止重复尝试。
SCRIPT KILL成功只是止血，脚本调用入口和重试队列仍要处理。
写脚本卡住时不要贸然强杀进程
官方文档指出，已执行写操作的脚本不能使用SCRIPT KILL终止。剩余的强制恢复手段可能涉及 SHUTDOWN NOSAVE 或进程终止，会造成停机，并可能丢失尚未持久化的数据。
在做任何强制操作前，确认主从拓扑、AOF/RDB状态、最后持久化时间、复制偏移和故障切换方案：
redis-cli INFO replication
redis-cli INFO persistence
redis-cli ROLE有Sentinel、Cluster或托管高可用服务时，应按既定故障转移流程处理，避免单机命令制造双主。强制关闭属于数据风险操作，不能为了让端口快速响应就直接执行。
不要把lua-time-limit无限调大
lua-time-limit 控制脚本运行多久后Redis开始记录超时并允许处理少数管理命令。把它调大不会让低效脚本变快，只会延后BUSY保护出现，让其他请求等待更久。
读取当前值：
redis-cli CONFIG GET lua-time-limit临时缩短也不能自动终止已经写数据的脚本。参数调整应建立在业务脚本正常耗时分布上，并写入受控配置。时间限制是故障可见性边界，不是脚本性能优化器。
把大循环拆成可控的小批次
Redis脚本执行具有原子性，运行期间会阻塞主线程。不要在脚本里对不受控的大集合做全量遍历，也不要把KEYS式扫描、复杂排序或大量网络输入塞进一次调用。
将任务改为固定批量，每批处理有限元素，并由应用保存游标或进度；可使用SCAN家族分段获取键，再对小集合执行脚本。业务需要跨批一致性时，重新设计状态机、幂等键和失败恢复，而不是追求一次脚本包办全部工作。
单次脚本的工作量必须有上限，并能在接近最坏数据量时完成压测。 平均数据量正常不能证明峰值安全。
监控脚本延迟和调用规模
开启并查看延迟监控、慢日志和命令统计：
redis-cli SLOWLOG GET 50
redis-cli INFO commandstats
redis-cli LATENCY LATEST长脚本完成后才能以完整形式进入慢日志，故障期间还要依靠应用侧计时、日志和调用参数。对EVALSHA、FCALL设置单独的延迟与错误率告警，并记录脚本版本。
需要复现大集合脚本时，可在 萤光云 创建隔离实例，也可通过 LightNode 部署临时节点。使用生成数据或脱敏样本，不要上传生产AOF、RDB和密码。
恢复后的验收标准
先确认PING恢复、BUSY错误归零，再观察命令延迟、连接数、复制和持久化：
redis-cli PING
redis-cli INFO stats
redis-cli INFO replication
redis-cli INFO persistence重新启用任务前，用接近最大规模的数据测试修改后的脚本，确认执行时间远低于限制，并验证重复执行、超时和中途失败不会破坏业务状态。上线后逐步放量，避免积压队列同时涌入。
验收标准是实例响应恢复、数据一致性得到确认、问题脚本有明确调用方、单次工作量受控，而且同类慢脚本能被提前告警。
常见问题
SCRIPT KILL会回滚已经执行的写入吗？
不会靠回滚解决。脚本一旦执行写命令，Redis会拒绝SCRIPT KILL，以保护原子性。
重启Redis能立即解决BUSY吗？
进程重启会中断脚本，但可能丢失未持久化数据，并造成业务停机。高可用环境还会影响拓扑，不能作为默认动作。
把Lua脚本换成pipeline就一定更好吗？
不一定。pipeline减少网络往返，但不提供Lua脚本相同的原子性。应根据一致性要求重新设计批次与幂等逻辑。
温馨提示
Redis脚本适合短小、确定、可预测的原子操作。脚本中一旦出现随数据量增长的大循环，就应把最坏耗时纳入上线门槛，并准备可中断、可续跑的应用层方案。
