Redis 5.0.6过期键未自动清理，内存暴涨问题求助

根据你提供的信息，首先需要明确一个关键矛盾点：你提到所有键的过期时间通常约2小时，但info keyspace返回的avg_ttl=54395557换算后是约629天，这说明绝大多数键的实际存活时间远超出预期，这才是内存暴涨的核心原因，而非Redis不清理过期键。以下是具体的根因分析和排查方向：

一、应用层过期时间设置错误（最可能） #

这是此类问题的头号诱因，需优先排查：

• 时间单位混淆：Redis的SET命令中，EX参数对应秒，PX对应毫秒。如果你的代码误将2小时（7200秒）以PX参数传入，实际过期时间仅为7.2秒；反之，若将毫秒值以EX传入（比如传7200000），则过期时间会变成约83天，直接导致内存持续增长。
• 过期时间计算逻辑错误：代码中可能误用了错误的时间戳（比如把未来几年的时间设为过期时间），或者在计算过期时长时出现数值错误（比如将小时当成天计算）。
• 异常分支跳过过期设置：在某些异常场景下（比如缓存写入失败重试、业务逻辑分支遗漏），代码未执行EXPIRE或带过期参数的SET命令，导致键变成永久有效。

二、Redis定期删除机制未有效触发 #

Redis的过期键清理依赖惰性删除（访问键时检查并删除过期键）和定期删除（每隔100ms随机抽查部分过期键）：

• 如果Redis实例长期处于低负载状态，定期删除的抽查频率可能不足以快速清理大量过期键，但结合你的avg_ttl数值，此可能性极低——若键真的过期，avg_ttl应接近0或为负数，而非超大正数。
• 若你修改过hz配置（默认值为10），将其设为过低数值（比如1），会导致定期删除的执行频率大幅降低，延缓过期键清理。

三、内存淘汰策略配置问题 #

检查Redis的maxmemory和maxmemory-policy配置：

• 若maxmemory-policy设为noeviction，当内存达到maxmemory限制时，Redis会拒绝写入但不会主动删除任何键（包括过期键）；若maxmemory未设置或设置过高，内存会持续增长直到达到系统/K8s限制。
• 若使用allkeys-lru等淘汰策略，只有当内存达到maxmemory阈值时才会触发淘汰，但如果键实际未过期，即使内存溢出也不会被清理。

四、Redis 5.0.6版本的已知bug #

Redis 5.0.6存在部分与过期键相关的已知bug，比如在RDB/AOF重写过程中，过期键的清理逻辑可能出现异常。你可以查看Redis官方发布说明，确认是否有相关bug在后续5.0.x稳定版本（如5.0.14）中被修复，必要时可尝试升级版本验证。

排查步骤 #

1. 随机选取几个键，执行TTL <key>或PTTL <key>命令，查看实际剩余存活时间，确认是否与预期的2小时一致；
2. 审计应用代码中设置过期时间的逻辑，重点检查时间单位、参数传递和异常分支；
3. 查看Redis配置文件，确认hz、maxmemory和maxmemory-policy的设置是否合理；
4. 检查Redis日志，排查是否存在过期键清理失败、内存不足等报错信息；
5. 若怀疑版本bug，升级至5.0.x分支的最新稳定版本进行测试。

内容的提问来源于stack exchange，提问作者bryce