Redis为什么会出现内存泄漏的假象？排查Lua脚本中未设置过期的临时变量

Redis内存持续上涨可能源于Lua脚本中未设置过期时间的临时键，如set、hset、zadd写入后遗漏expire，导致“孤儿键”累积；需用redis-cli --scan结合object freq和ttl定位，并按业务语义修复。

Redis内存持续上涨但没发现大Key？先查Lua脚本里有没有漏掉expire

Redis本身的设计机制决定了它不会因为执行Lua脚本就直接导致内存泄漏。但问题往往出在细节里：脚本中创建的临时键，比如用set或hset写入的那些，如果忘记配上expire，就会变成“钉子户”，永久驻留在内存中。尤其是在高频调用的场景下，这类“孤儿键”会悄无声息地不断累积，最终表现为内存使用率稳步攀升，很容易被误判为底层的内存泄漏。

Lua脚本里哪些操作容易埋雷？重点关注这三类写入

Redis的Lua沙箱环境为了安全，禁止执行expire以外的后台命令，但写入数据是完全允许的。恰恰是这种“只写不管”的写法，埋下了隐患。下面这几类操作尤其需要警惕：

• redis.call('set', 'tmp:'..KEYS[1], 'value') —— 如果后面没有紧跟一行redis.call('expire', ...)，这个键就获得了“永生”。
• redis.call('hset', 'cache:'..ARGV[1], 'field', ARGV[2]) —— 哈希结构本身不支持字段级过期，如果外层key没有设置生命周期，整个哈希就会一直存在。
• redis.call('zadd', 'sorted_tmp_'..os.time(), 1, 'item') —— 用时间戳拼接key看似能保证唯一性，但如果没有配套的清理逻辑，这些“一次性”的键积压起来，就是未来的定时冲击波。

怎么快速定位问题脚本？用redis-cli --scan + object freq交叉验证

单纯盯着内存监控曲线看是没用的，关键在于精准识别出那些“不该存在却长期存活”的键。排查可以遵循以下步骤：

• 先用redis-cli -a --scan --pattern "tmp:*"扫描所有疑似临时键前缀的键。这个模式匹配是定位问题的第一步。
• 对扫描结果进行抽样，执行object freq 命令。如果返回值是(integer) 0，意味着这个键几乎没被访问过，是废弃键的可能性就非常高了。
• 再用ttl 命令确认一下。如果返回-1（永不过期）或者-2（键不存在），都需要高度警惕。前者是元凶，后者则提示可能已经自动清理，但需要确认清理逻辑是否完备。
• 如果还无法确定，可以结合script debug yes开启调试模式（生产环境务必谨慎，仅在排查时使用），复现请求，观察脚本的实际执行路径，看看键到底是在哪一步被创建却未被清理的。

修复方案不是加expire就完事，得匹配业务语义

发现问题后，直接在所有写入操作后硬塞一个expire命令，听起来简单，实则可能引入竞态条件或数据逻辑错乱。正确的修复思路，必须与业务场景相匹配：

• 临时缓存类：统一使用setex或psetex原子操作来替代set + expire的两步走，彻底消除两步操作之间的时间窗口风险。
• 哈希/集合类结构：将整个数据结构封装在一个带过期时间的顶级key之下。记住，Redis不支持哈希字段或集合元素的独立TTL，生命周期必须由外层key控制。
• 需要精确控制清理时机的：改用redis.call('del', 'tmp_key')在业务逻辑结束时显式删除。这种方式比依赖过期时间更主动、更可控。
• 彻底检查调用点：所有使用eval命令的地方，都必须回头检查其引用的Lua脚本源码。千万别相信“这个脚本很久没动过了”这种说法，高频执行路径上的任何微小变更，其影响都会被无限放大。

最棘手的情况，是多个Lua脚本共享同一套临时key的命名空间，却又各自管理生命周期。这时候，只修复其中一个脚本往往无济于事，必须拉通梳理整个调用链路上key的生成和销毁契约，制定统一的规范。这才是治本之道。