redis集群中script kill无法强制终止超时lua脚本，因其仅作用于当前连接节点且仅支持可中断等待态；脚本若进入纯计算或不可中断状态则完全失效，根本解决需源头限流、禁用高危操作并拆分执行。
Redis 集群中 Lua 脚本超时后不能靠 SCRIPT KILL 强制终止 —— 这是硬限制，不是配置问题。 因为集群模式下脚本执行发生在单个分片（slot）的主节点上，而 SCRIPT KILL 只对当前连接所在节点有效，且仅适用于“尚未执行完毕但可安全中断”的阻塞型脚本（比如 SLEEP），不适用于已进入不可中断状态（如陷入死循环、等待阻塞命令返回）的脚本。
为什么 SCRIPT KILL 在集群里经常失效
Redis 的 SCRIPT KILL 命令本质是向当前连接所连节点发送中断信号，前提是脚本仍在“可中断点”等待（例如刚调用完 redis.call("BLPOP", ...) 但还没拿到数据）。一旦脚本进入原子执行阶段（如大量本地循环、或调用非阻塞命令密集运算），Redis 不会插入中断检查点，SCRIPT KILL 就完全无响应。
- 集群环境下，你可能连错了节点：脚本实际运行在负责该 key slot 的主节点，但你
redis-cli -c连的是随机节点或从节点，SCRIPT KILL发送到错误节点，自然无效 -
SCRIPT KILL不支持跨节点广播，没有集群级“杀所有副本上的同名脚本”能力 - 若脚本已触发
TIMEOUT并被 Redis 主动标记为“killed”，再次执行SCRIPT KILL会返回(error) ERR No scripts in execution right now，但这不代表脚本真正退出了 —— 它可能还在 CPU 上跑着
真正可控的并发控制手段：从源头限流 + 超时兜底
别依赖运行时 kill，要让脚本根本没机会跑飞。关键在客户端和服务端双侧约束：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 客户端统一使用带超时的连接：比如 Jedis 设置
socketTimeout=5000，Lettuce 设置CommandTimeout；超时触发后主动断连，避免连接卡死 - 服务端启用
lua-time-limit（默认 5000 毫秒），它只对“阻塞等待型”脚本生效（如BLPOP），对纯计算型无效 —— 所以必须配合代码审查 - 禁止在 Lua 中做任何非 Redis 操作：比如
for i=1,1000000 do ... end、string.gsub处理超长文本、JSON 解析大 payload —— 这些都应前置到应用层 - 对必须用 Lua 的场景，拆成小步调用：用
redis.call("EVALSHA", ...)+ 客户端缓存 sha1，配合幂等设计，避免单次执行过久
当脚本真卡死时，唯一可靠的恢复方式
如果确认某个主节点上的 Lua 脚本已失控（INFO replication 显示 loading: no 但 used_cpu_sys 持续飙升，CLIENT LIST 里有 cmd=eval 且 idle 为 0），不要反复试 SCRIPT KILL：
- 先用
CLUSTER NODES确认该 key 对应的 master 节点 IP 和端口 - 直连那个 master（绕过
-c模式），再执行SCRIPT KILL—— 成功率略高，但依然不保证成功 - 若仍无响应，唯一办法是
redis-cli -h $MASTER_IP -p $PORT DEBUG RELOAD（需config set stop-writes-on-bgsave-error no且无持久化风险）或重启该 master 节点（注意 failover 影响） - 切勿在生产环境对集群节点执行
DEBUG SEGFAULT或其他破坏性命令
最常被忽略的一点：Lua 脚本的“并发数”其实由客户端连接数和脚本执行时长共同决定，而不是 Redis 自身的线程模型。一个耗时 2s 的脚本，10 个并发连接就会吃掉 20 秒的单核等效时间 —— 所以压测时务必用真实业务脚本，而不是空 return 1。
