如何处理Redis因Lua脚本占用过多内存引发的淘汰

lua-time-limit 限制脚本执行最大毫秒数而非内存，设为0或过小仅触发script kill中断，无法阻止内存暴涨；脚本中redis.call的真实读写会直接影响volatile-lru/ttl等淘汰策略。

如何处理redis因lua脚本占用过多内存引发的淘汰_设置lua-time-limit

lua-time-limit 不是用来限制内存占用的

lua-time-limit 配置项控制的是 Lua 脚本执行的**最大毫秒数**，不是内存上限。把它设成 0 或很小的值（比如 5），只会让超时脚本被 SCRIPT KILL 中断，但不会阻止脚本本身分配大量内存——比如用 table.insert 循环生成百万级数组，或用 redis.call('GET', ...) 批量读取大 value，这些操作在超时前就可能把内存打爆。

真正影响内存淘汰的是脚本执行期间的数据访问模式

Lua 脚本执行时是单线程原子运行的，它调用的 redis.call 命令会真实读写数据，触发的 key 访问行为会直接影响淘汰策略判断：

如果脚本反复读写带 TTL 的 key（比如做计数+过期检查），可能让 volatile-lru 或 volatile-ttl 策略更频繁地触发淘汰
如果脚本里 redis.call('SET', 'bigkey', string.rep('x', 10 写入超大 value，直接推高 <code>used_memory，更快触达 maxmemory 上限
脚本执行完才释放临时变量，所以长脚本 = 更久持有内存引用，GC 延迟更明显

防止 Lua 导致 OOM 的实际配置组合

光调 lua-time-limit 没用，得配合其他硬性约束：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

必须设置 maxmemory，例如 maxmemory 2gb，否则 Redis 会吃光系统内存后被 OOM Killer 杀掉
搭配使用 maxmemory-policy allkeys-lru 或 allkeys-lfu，避免 noeviction 下写失败引发业务异常
通过 ACL 限制非可信用户执行 EVAL/EVALSHA，例如：ACL SETUSER appuser -EVAL -EVALSHA -SCRIPT
若用脚本做聚合计算，提前在应用层控制输入规模（如限制 KEYS 数量、ARGV 总长度），别让脚本承担“防呆”责任

调试时怎么确认是 Lua 引起的内存压力

别只看 INFO memory，重点查这几项：

used_memory_peak_human：峰值内存，对比当前 used_memory_human，差值大说明有大对象未释放（可能是脚本残留）
mem_allocator 和 mem_fragmentation_ratio：碎片率 > 1.5 且 used_memory_rss 远高于 used_memory，说明脚本分配/释放不均导致碎片
执行 SCRIPT EXISTS <sha></sha> 或 SCRIPT FLUSH 后观察内存是否回落——如果回落明显，说明缓存的脚本体（尤其带大 table 初始化的）占了大量字典空间