redis内存管理包含两套独立机制：过期清理（惰性+定期）始终运行，负责删除已到期键；内存淘汰（maxmemory触发）仅在内存超限时启用，决定淘汰哪些键腾空间，二者条件不同、互不干扰。
maxmemory 触发时才启用内存淘汰，而数据过期清理（惰性+定期）始终运行——两者不竞争、不分主次，只是在不同条件下各自干活。
内存淘汰和过期清理是两套独立机制
很多人误以为“key 过期了就会被立刻删掉”，其实不是。EXPIRE 设置的只是“到期时间戳”，Redis 不会主动盯梢；真正清理动作靠的是两个不重叠的路径：
一是过期策略（expires 字典 + 惰性/定期检查），负责“该不该删”；
二是内存淘汰（maxmemory + maxmemory-policy），负责“删谁来腾地方”。
它们触发条件完全不同：
• 过期清理：只要 key 到了 TTL，就可能被惰性访问时顺手删，或被定期任务抽中删；
• 内存淘汰：只有写入新数据且 used_memory > maxmemory 时，才启动采样淘汰。
为什么用了 allkeys-lru 还有大量过期 key 滞留？
因为 allkeys-lru 只看访问时间，不看是否已过期——它淘汰的是“最久没用但还没过期”的 key，而那些早已过期却没人访问的 key，依然躺在内存里。
这种现象在以下场景特别明显：
• 批量设置相同 EXPIREAT（比如凌晨统一设为 24 小时后过期），导致大量 key 在同一秒变成“过期但未删除”状态；
• 热点数据访问频繁，冷数据长期无人 touch，惰性删除永远不触发；
• hz 值太低（如默认 10），定期删除抽样频率不够，漏掉大量过期 key。
结果就是：内存明明还有空间，但 INFO memory 显示 expired_keys 持续上涨，mem_used 却没下降。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
volatile-lru 和 allkeys-lru 的关键区别不在“lru”，而在“volatile”
volatile-lru 和 allkeys-lru 都用近似 LRU 算法，但筛选范围天差地别：
• volatile-lru：只从设置了 EXPIRE 的 key 中选，哪怕你有 100 万个永久 key（没设过期），它也完全无视；
• allkeys-lru：扫描全部 key，包括没设过期时间的，所以能真正释放空间。
容易踩的坑：
• 误以为 volatile-lru 更“安全”，结果发现内存打满后，大量永久 key 把空间占死，新数据写不进；
• 在混合场景（部分 key 永久、部分 key 临时）下，用 volatile-lru 却没给临时 key 足够过期时间，导致可淘汰池子太小；
• volatile-ttl 看似合理，但它只比 TTL 大小，不考虑访问热度，可能把刚被读过的 key 提前踢掉。
noeviction 策略下，过期键清理失效会直接导致 OOM
如果配置了 maxmemory-policy noeviction（默认值），那 Redis 就彻底放弃主动腾内存——它既不淘汰非过期 key，也不保证过期 key 一定被及时清理。
这时一旦出现：
• 定期删除没抽中大量过期 key；
• 这些 key 又长期不被访问（惰性删除不触发）；
• 新写入持续增加（比如日志类 key 每分钟生成一批）；
就会迅速触达 used_memory > maxmemory，然后所有写命令返回 OOM command not allowed when used memory > maxmemory。
这不是 bug，是设计使然：noeviction 的本意就是“宁可拒绝写入，也不动已有数据”，所以它对过期清理的依赖极高。生产环境几乎不用它做缓存，除非你确定所有 key 都带合理 TTL 且访问足够频繁。
hz 是否调得够高、以及有没有监控 expired_keys 和 evicted_keys 这两个指标——它们才是内存健康的真实晴雨表。
