Redis 数据淘汰策略与内存碎片清理管理机制-linux运维-PHP中文网

redis淘汰策略与内存碎片清理是内存管理的前后两环：淘汰策略决定“该删谁”，碎片清理确保“删后空间真正回收”；配合不当会导致“假释放”，即内存显示已淘汰却腾不出空间。

redis 数据淘汰策略与内存碎片清理管理机制

Redis 数据淘汰策略和内存碎片清理不是两个孤立动作，而是内存管理的前后两环：淘汰策略解决“该删谁”的决策问题，碎片清理解决“删了之后空间能不能真正回收”的落地问题。两者配合不好，就可能出现“内存显示已淘汰，实际却腾不出空间”的假释放现象。

核心判断依据是业务数据是否混存永久配置与临时缓存：

如果所有 key 都带 TTL（比如用户会话、验证码、商品临时页），优先用 volatile-lfu——它比 volatile-lru 更稳，能长期留住高频访问的热点，避免刚热起来就被踢掉
如果 Redis 里既有带过期的缓存，也有永久存储的字典表、开关配置等，必须用 volatile-* 系列（如 volatile-lfu 或 volatile-ttl），否则 allkeys 类策略可能误删关键配置
如果 Redis 纯作缓存，不存任何业务主数据，推荐 allkeys-lfu——全局视角下冷热区分更准，长期命中率更高；allkeys-random 和 volatile-random 生产环境禁用
noeviction 是默认策略，但绝不适合缓存场景——写入直接报 OOM，接口大面积失败，只适用于极小规模、写入极少的配置中心类用途

Redis 不会在内存满的瞬间同步扫库删除，而是分层应对：

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

下载

定时驱逐：每秒自动触发（serverCron），在命令执行前随机抽检一批 key，按策略采样淘汰。特点是小步快跑、不卡主线程，但属于“预防性清扫”
懒惰驱逐：当写入命令因内存不足被拒绝时才启动，主线程同步执行一轮完整淘汰，直到腾出足够空间。这是兜底动作，若未开启 lazyfree-lazy-eviction yes，大 key 删除可能引发毫秒级延迟尖刺

也就是说，即使配置了 allkeys-lfu，也不是每次 SET 都立刻淘汰；而是在写不进去时，才真正开始“踢人”。所以压测时观察 RT 波动，要重点盯住 evicted_keys 和 mem_blocked_clients 这两个指标。

淘汰 key 只是释放 Redis 对象内存，但底层 malloc 分配器未必能把这块内存交还给操作系统。结果就是 used_memory 下降了，mem_fragmentation_ratio 却仍大于 1.5，甚至持续走高。

常见诱因：频繁写入删除不同大小的 key（尤其是大量小 key + 少量大 hash），导致内存块散乱、无法合并归还
验证方式：redis-cli info memory | grep mem_fragmentation_ratio，>1.5 值得关注，>2.0 属于严重碎片化
缓解手段：activedefrag yes（Redis 4.0+）开启主动碎片整理，配合 active-defrag-threshold-lower 10 等参数，在 CPU 空闲时自动合并空闲块；但要注意它本身会消耗 CPU，需避开业务高峰启用

过期键清理（惰性 + 定期）和内存淘汰是两套独立机制。定期删除只是抽样清理，对短期爆发式过期（比如批量发券后集中失效）响应滞后；惰性删除又依赖访问触发。所以：

不能靠设置大量短 TTL 来替代淘汰策略——过期堆积照样撑爆内存
如果业务存在明显过期潮汐（如整点清空日志缓存），建议搭配 volatile-ttl 策略，让 Redis 优先清理“马上就要死”的 key，降低突发压力
监控 expired_keys 和 evicted_keys 的比值：如果前者远高于后者，说明过期机制基本能兜住；如果后者持续上涨，说明写入速率长期超过过期清理能力，必须优化 TTL 设计或扩容