redis lua脚本无法靠lua-time-limit自动中断，因其仅允许script kill触发而非强制终止；需客户端限流、服务端配置（建议设为2000ms并同步集群）、脚本层加循环守卫与原生命令替代三重防护。
Redis Lua脚本卡死无法靠超时自动中断，必须从客户端限流、服务端约束、脚本写法三侧同时设防。
为什么lua-time-limit不等于“超时自动杀”
这个配置项只是告诉 Redis：“单次 redis.call() 执行超过多少毫秒后，允许你发 SCRIPT KILL”。它不会主动中断脚本，也不检查纯计算循环。比如：for i = 1, 1000000 do end 或 while true do redis.call("PING") end 都能绕过它的计时逻辑。
常见误判是把 lua-time-limit 2000 当成保险丝——结果脚本在 CPU 上跑满 10 秒，返回 BUSY，但主线程早已被锁死。
- 默认值
5000太宽松，建议生产环境统一设为2000（2 秒） - 改完必须执行
CONFIG REWRITE或重启，否则不生效 - 集群中所有 master 节点该值必须一致，否则超时状态不一致
SCRIPT KILL 在哪些场景下必然失效
SCRIPT KILL 不是万能命令，它只对“尚未执行任何写操作”的脚本有效。一旦脚本里出现 redis.call("SET", ...)、redis.call("INCR", ...) 等修改数据的调用，Redis 就会拒绝中断，并返回：(error) UNKILLABLE Sorry the script already executed write commands。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
此时脚本已进入不可中断状态，继续占用主线程，所有新请求返回 BUSY。
- 客户端连错节点：脚本实际运行在 slot 12345 的主节点，你却在从节点或随机节点上执行
SCRIPT KILL - 脚本已触发超时并被标记为 killed，但仍在 CPU 上跑 ——
SCRIPT KILL再执行会报ERR No scripts in execution right now，这是假象 - 集群模式下，
SCRIPT KILL不广播，无法跨节点终止同一脚本的副本
真正可控的优化手段：客户端 + 脚本层双约束
别等卡死再抢救，要在脚本跑起来前就掐住风险点。
- 客户端必须设置 socket timeout：Jedis 用
setSoTimeout(2500)，Lettuce 用CommandTimeout，Go 用context.WithTimeout(ctx, 2500 * time.Millisecond)—— 比服务端lua-time-limit更早一步断连 - 所有循环强制加守卫：
for i = 1, math.min(1000, #KEYS) do ... end，禁用while true和无界for - 批量操作优先用原生命令：
MGET替代循环GET，DEL替代循环DEL单 key - 上线前实测耗时：用
redis-cli --eval script.lua keys , args --timeout 3包一层，压测最大输入规模下的执行时间
当脚本真卡死，只剩两个真实选项
确认脚本已失控（CLIENT LIST 显示 cmd=eval 且 idle=0，INFO commandstats 中 cmdstat_eval:usec_per_call > 1000000），就别反复试 SCRIPT KILL。
-
SHUTDOWN NOSAVE：立即终止进程，不触发 RDB/AOF，数据丢失但一致性有保障；集群会触发 failover，需评估影响范围 - 直接
kill -9 <pid></pid>：效果类似，但跳过 Redis 自清理逻辑，不推荐
最常被忽略的一点：脚本里看似安全的 redis.call("GET", "bigkey")，在高并发下可能批量拉取 MB 级 value，迅速推高 used_memory 并触发淘汰策略失衡——这比超时更难监控，也更易引发雪崩。
