redis lua脚本会阻塞整个实例，因其在单线程事件循环中执行，eval/evalsha独占主线程直至完成或超时；最易阻塞的操作包括无上限循环、keys全库扫描、高频redis.call调用及深度递归；必须配置lua-time-limit、maxmemory与slowlog-log-slower-than参数兜底。
Redis Lua脚本为什么会阻塞整个实例？
因为 Redis 是单线程事件循环模型，EVAL 或 EVALSHA 一旦开始执行 Lua 脚本，就会独占主线程，直到脚本返回或被强制中断。哪怕只是多嵌套两层 for 循环、或对一个大 Hash 做全量 HSCAN，都可能卡住几百毫秒——这期间所有其他客户端的命令（包括 PING）都在排队等待。
哪些 Lua 操作最容易触发长时间阻塞？
不是所有脚本都危险，但以下模式几乎必然引发问题：
-
while true do ... end或未设上限的for i = 1, 10000000 do—— CPU 密集型空转 - 在脚本里反复调用
redis.call('HGETALL', KEYS[1])—— 一次性拉取数万字段，内存+CPU 双爆 - 用
redis.call('KEYS', 'user:*')——KEYS是 O(N) 全库扫描，严禁在脚本中出现 - 递归调用自身或深度嵌套函数，且无退出条件判断
这些操作在本地测试可能“秒出”，但在生产环境数据量上来后，极易突破 lua-time-limit 阈值（默认 5000ms），触发 SCRIPT KILL 或直接 OOM。
必须配置的三个关键参数
仅靠写脚本规范不够，Redis 服务端必须做硬性兜底：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
lua-time-limit 100：把默认 5000ms 改成 100ms。这是第一道防线，超时后 Redis 会尝试中断脚本（注意：仅对可中断点有效，比如redis.call()调用之间） -
maxmemory 4gb+maxmemory-policy allkeys-lru：防止脚本里误存超大临时结构（如table.insert(big_array, ...)）耗尽内存 -
slowlog-log-slower-than 10000：把慢日志阈值设低些，确保能捕获到 >10ms 的脚本执行，便于后续SLOWLOG GET定位
改完记得 CONFIG REWRITE 持久化，别只用 CONFIG SET 临时生效。
替代方案：什么时候该放弃 Lua 脚本？
不是所有“需要原子性”的场景都适合写 Lua。遇到以下情况，换架构更稳妥：
- 要处理的数据跨多个 key，且这些 key 不在同一个 slot（Redis Cluster 下）→ 强制加
{}HashTag 会导致热点，不如拆成幂等写 + 外部协调（如用 Redis Stream 做任务队列） - 逻辑涉及外部 HTTP 调用、文件读写、或任意不可控延迟 → Lua 根本不支持，强行用
os.time()等模拟只会让阻塞更隐蔽 - 脚本里需要做 JSON 解析、正则匹配、或 Base64 编解码 → Redis 内置 Lua 不带这些库，自己实现效率极低，应提前在客户端序列化好再传入
真正难的从来不是“怎么写一个能跑的 Lua 脚本”，而是判断“这个需求到底该不该放在 Redis 里做”。
