redis单线程模型下lua脚本独占主线程，执行耗时操作会阻塞所有请求，导致延迟飙升、超时激增；eval/evalsha运行期间其他命令无法执行，包括info、ping等，集群节点还可能因心跳超时被标记为fail。
Redis Lua脚本里执行耗时操作，等于直接卡住整个节点的主线程——所有新请求会排队等待，延迟飙升，超时激增，不是“慢一点”，而是“全堵死”。
为什么一次长脚本会让其他命令全卡住
Redis 主线程是单线程事件循环，EVAL 或 EVALSHA 一旦开始执行，就独占该线程，直到脚本返回或被强制中断。期间：其他客户端发来的任何命令（包括 INFO、PING、心跳）都进不了执行队列；网络读写虽由 IO 线程处理（Redis 6.0+），但命令解析和执行仍得等这个 Lua 脚本让出控制权。
- 典型现象：
CLIENT LIST中看到多个连接cmd=eval且idle=0、age持续上涨 - 监控指标：
INFO commandstats里cmdstat_eval:usec_per_call突然超过 1000000 微秒（即 1 秒） - 集群下更危险：该节点的
CLUSTER NODES状态可能变为fail，因为心跳响应超时
哪些操作在 Lua 里实际很“重”
表面看只是几行代码，但在 Redis 单线程上下文中，它们会显著拉高 CPU 占用和执行时间：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
redis.call("SMEMBERS", key)：若集合有 10 万成员，返回结果在 Lua 栈中展开为大 table，内存暴涨且 GC 不及时 - 用
for循环调用redis.call("GET", keys[i])500 次：每次redis.call都触发完整命令流程（解析、权限检查、键路由），实测 500 次比MGET慢 4 倍以上 -
os.date("%Y%m%d", redis.call("TIME")[1])：看似简单，但os.date是纯 CPU 计算，在 lua-time-limit（默认 5000ms）内极易超时 - 遍历
ARGV做正则匹配（string.match(val, "pattern")）或 base64 编解码：这些本该由客户端完成的计算，挤占了 Redis 宝贵的主线程 CPU
怎么判断你的脚本是否已成瓶颈
不能只看本地测试耗时，要结合生产环境真实负载来验证：
- 上线前用
SCRIPT LOAD预加载，再用EVALSHA执行，并观察INFO stats中的instantaneous_ops_per_sec是否骤降 - 对脚本加计数器保护：比如
for i = 1, math.min(200, #KEYS) do ... end，避免#KEYS过大时无限循环 - 客户端必须设置 socket timeout（如 Jedis 的
setSoTimeout(3000)），否则线程会在 read 阶段永久挂起 - 高频调用脚本的服务，务必在入口层做 QPS 限流（例如令牌桶限制每秒最多 30 次
EVAL），防止单点打满
真正难防的不是语法错误，而是那些在低流量下跑得飞快、一到大促就让整个 Redis 节点失联的“轻量级”脚本——它们往往藏在条件分支里，只在特定参数组合下才触发 full scan 或深度遍历。
