redis lua脚本执行期间会完全阻塞主线程，因其在单线程中独占执行，所有其他客户端请求必须排队等待；redis 6.0+虽用多线程处理网络io，但命令解析与执行（含eval及redis.call）仍由主线程完成，故keys*、scan无limit、循环调用redis.call等操作均会导致不可控阻塞。
Redis Lua脚本执行期间无法保证响应性——它会完全阻塞主线程，其他所有客户端请求必须排队等待，直到脚本执行完毕。
为什么Lua脚本一执行，Redis就“卡住”了
Redis 6.0+ 虽然用多线程处理网络读写（IO），但命令执行（包括 EVAL 和所有 redis.call()）仍在单一线程中完成。Lua脚本被当作一个整体命令看待，从解析、加载到执行全程独占主线程。
- 脚本里每调用一次
redis.call("GET", "key")，都直接走内部执行路径，不重新入队、不切换上下文 - 哪怕只有一行
redis.call("KEYS", "*")，也会让整个 Redis 实例暂停响应数秒甚至更久 - 网络断开不影响脚本继续执行；超时（默认
lua-time-limit 5000）仅记录警告，不会自动中断
哪些操作会让阻塞时间不可控
真正危险的不是逻辑复杂，而是触发高开销或不可预测耗时的操作：
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
-
KEYS *：全量扫描 keyspace，时间随数据量线性增长 -
SCAN循环未设 limit 或游标未正确传递：可能遍历大量无效 slot - 在脚本里做字符串拼接 + 多次
redis.call()：每次call都有固定开销，5 次以上明显拖慢 - 用
ARGV动态构造 key 名（如"user:" .. ARGV[1]）：集群模式下直接报CROSSSLOT错误，但错误前已占用线程
怎样缓解阻塞影响（不是消除）
你不能绕过单线程限制，但可以降低风险面：
- 用
SCRIPT LOAD+EVALSHA替代重复发送完整脚本，减少网络和解析压力 - 把批量操作压进单次
mget/mset，而不是循环调用get/set - 关键判断逻辑尽量前置：比如先用
EXISTS快速筛掉无效 key，再进复杂分支 - 对超时敏感场景，提前在客户端加 fallback：比如
EVAL超过 800ms 就主动SCRIPT KILL（注意仅对无写操作的脚本安全）
最易被忽略的一点：脚本里没报错 ≠ 没阻塞。只要它还在跑，Redis 就没空理别人——哪怕只是 sleep(0) 这种伪操作，在 Lua 沙箱里也不存在，你只能靠设计让它快进快出。
