Redis集群中Lua脚本不会触发传统死锁，但会因单线程执行而阻塞整个节点；无限循环脚本导致该节点所有命令超时，需通过CLIENT LIST、INFO commandstats及CLUSTER NODES识别异常，并依赖lua-time-limit、计数器循环、客户端超时与限流等机制防控。
Redis集群中Lua脚本不会触发传统“死锁”，但会阻塞整个节点
Redis 是单线程执行 Lua 脚本的，EVAL 或 EVALSHA 一旦开始运行，就独占当前 Redis 实例的主线程。所谓“死锁”在集群里其实不是多个客户端互相等待资源，而是某个客户端提交了一个无限循环的 Lua 脚本（比如 while true do end），直接卡死该节点上所有后续命令——包括心跳、槽迁移、甚至 INFO 查询都会超时。
如何识别正在跑飞的 Lua 脚本
关键看 redis-cli 的 SCRIPT DEBUG 和运行时指标：
-
redis-cli -p 6380 DEBUG OBJECT key没用——它不适用于 Lua 执行态 - 真正有效的是：
redis-cli -p 6380 CLIENT LIST，找cmd=eval且age持续增长、idle接近 0 的连接 - 配合
INFO commandstats查看cmdstat_eval:calls=是否突增，usec_per_call是否飙高（比如 >1000000 微秒） - 集群模式下还要注意：
CLUSTER NODES中对应节点状态是否变成fail?或长期无响应
防止 Lua 死循环的硬性约束和实操写法
Redis 本身不提供 timeout 参数给单个 EVAL，只能靠外部机制兜底 + 编码规范：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须启用
lua-time-limit配置（默认 5000 毫秒），超时后 Redis 自动中断脚本并返回ERR Error running script (call to f_...): @user_script: line 1: user_script:1: Script killed by user interrupt or timeout - 禁止在 Lua 中使用
while true、repeat ... until false；改用带明确计数器的循环，例如：for i = 1, math.min(1000, #keys) do redis.call("GET", keys[i]) end - 涉及 KEYS/ARGV 的批量操作，优先用原生命令（如
MGET）代替 for 循环调用GET，减少 call 开销和潜在迭代失控 - 集群环境下尤其注意：
KEYS数组必须全部落在同一 slot，否则EVAL直接报错CROSSSLOT Keys in request don't hash to the same slot，这不是死锁，但会让脚本根本跑不起来
客户端侧该做什么来降低风险
服务端拦不住所有问题，客户端得有熔断和降级意识：
- 调用
EVAL时必须设置 socket timeout（如 Jedis 的setSoTimeout(3000)），避免线程卡死在 read 阶段 - 对高频 Lua 调用做 QPS 限流，比如用令牌桶控制每秒最多 50 次
EVAL，防止单点打满 - 上线前用
SCRIPT LOAD预加载脚本，再用EVALSHA执行，既能省网络开销，也能通过提前校验规避语法类错误（虽然不防逻辑死循环） - 日志里记录每次
EVALSHA的sha1和耗时，当某sha1平均耗时突增 3 倍以上，立刻告警并人工核查脚本逻辑
真正麻烦的从来不是“怎么写一个正确的 Lua 脚本”，而是当它混在几十个微服务、上百个 EVALSHA 调用里悄悄变慢时，你能不能在节点 OOM 前 3 分钟发现那个多加了一层 while 的 f_7a2b9c...。
