2、别只背“八大策略”：从原理到调优，一文彻底搞懂 Redis 内存淘汰
面试官的核心考核意图
“兄弟们，面试 Redis 被问到内存淘汰，你是不是只会干巴巴地背那‘八大策略’？”
如果你的回答仅止于此，那么在面试官眼中，这最多只能算是个及格分。真正的技术专家，需要展现的是对底层原理的深刻洞见、对业务场景的权衡能力，以及解决实际问题的实战经验。
今天，我们就用一篇文章，带你从 原理、选型、再到监控调优，把 Redis 内存淘汰这个问题彻底打透，让你在面试官面前，真正秀出技术深度。
一、面试官的真实意图：他想听到什么？
当面试官抛出这个问题时，他期待的绝不是一个简单的名词列表。他试图通过这个问题，探查你四个层面的能力：
- 原理深度：你是否清楚淘汰机制何时被触发？内在的算法（如 LRU、LFU）是如何工作的？
- 选型能力：你是否能结合不同的业务场景，做出合理的技术选型？
- 实战经验：你是否了解相关的监控指标？遇到过类似大 Key 淘汰阻塞的问题吗？如何解决？
- 知识体系：你是否能将内存淘汰与 Redis 的其他机制（如
lazy-free）关联起来？
二、Why：触发机制是一切的起点
一个高水平的回答，应该从“Why”开始，即讲清淘汰机制的触发前提。
整个过程非常清晰，可以概括为“三部曲”：
- 设定上限：你必须在 Redis 配置文件中通过
maxmemory参数，为内存的使用量画下了一条“红线”。如果该值为0，则表示不限制内存，淘汰机制永远不会被激活。 - 执行写命令：当客户端执行一个写命令（如
SET,LPUSH等），导致 Redis 的内存占用即将冲破这条“红线”时，淘汰机制便被触发。 - 执行淘汰：Redis 会立刻根据预设的
maxmemory-policy策略，开始寻找并删除一个（或多个）“倒霉”的 Key，以释放空间。
这里有一个至关重要的注意事项：如果根据当前策略无法找到任何可供淘汰的 Key（例如，在 volatile-lru 策略下，所有 Key 都没有设置过期时间），Redis 将拒绝执行此次写命令，并向客户端返回一个 OOM (Out Of Memory) 错误。这正是默认策略 noeviction 的行为。
三、What：巧记八大策略
讲清楚了触发机制，我们再来看“What”——这八大策略。死记硬背效率低下，通过两个维度进行分类，可以瞬间理清逻辑。
第一个维度：淘汰范围
allkeys-*** 系列：从所有的 Key中进行淘汰。这适用于将 Redis 作为纯缓存**的场景，所有存入的数据都可以被视为待淘汰的候选者。volatile-*** 系列：仅从设置了过期时间（TTL）的 Key中进行淘汰。这非常适合混合数据**的场景，你可以将一部分需要持久化的核心数据（不设置TTL）和另一部分作为缓存的临时数据（设置TTL）共同存放在一个 Redis 实例中。
第二个维度：淘汰算法
- LRU (Least Recently Used)：淘汰最近最少使用的 Key。这是最经典的缓存淘汰算法。
- LFU (Least Frequently Used)：淘汰最不经常使用的 Key。这是 Redis 4.0 引入的策略，相比 LRU，它更能保护那些被长期、高频访问的“真·热点数据”，不易被偶然的批量访问“污染”。
- Random：随机淘汰。简单粗暴，CPU开销最小，但牺牲了缓存命中率的科学性。
- TTL：在
volatile-ttl策略中独有，专门淘汰那些剩余存活时间最短的 Key。
四、How：场景驱动的技术选型
理解了策略，接下来就是最能体现你实战经验的“How”——到底该怎么选？
记住这个简单的决策口诀：
- 纯缓存场景：如果你的 Redis 完全用作缓存，数据没了可以从后端数据库再加载，那么**首选 **
allkeys-lfu。如果你的 Redis 版本低于 4.0，那么allkeys-lru是一个稳妥的备选方案。 - 混合数据场景：如果你既有需要持久化的数据，又有缓存数据，那么就使用
volatile-lfu** 或volatile-lru。但此时必须牢记一个前提：一定要给你需要作为缓存的数据设置上 TTL！** 否则，淘汰机制将无的放矢，最终导致 OOM。
五、Ops：用数据说话的监控与调优
选择了策略，如何验证其效果？这就进入了运维监控（Ops）环节，也是你展现专业度的绝佳机会。通过 INFO 命令，我们可以获取 Redis 的“体检报告”，其中有两个指标是必须死死盯住的。
**核心指标（一）：内存碎片率 **mem_fragmentation_ratio
定义：
操作系统实际分配给 Redis 的内存 (used_memory_rss)除以Redis 自身逻辑上占用的内存 (used_memory)。通俗地讲，就是你跟系统要了多少地，和你实际盖了多少房的比值。指标解读：
健康范围 (1 ~ 1.5)：比值略大于1是正常的，代表内存分配本身存在少量开销和碎片。
警告区 (> 1.5)：说明内存碎片过多，你的“地盘”里全是无法利用的“坑”，导致严重的内存浪费，需要警惕。
危险区 (：这是最危险的信号！它意味着 Redis 需要的内存比操作系统给的物理内存还多，系统已经开始使用硬盘作为虚拟内存（Swap）。这对 Redis 来说是致命的性能杀手**，响应速度会急剧下降，必须立即处理。
核心指标（二）：缓存命中率
定义：
命中次数 (keyspace_hits)除以总请求次数 (hits + misses)的比例。指标解读：
这个值没有绝对标准，但对于一个健康的缓存系统，我们通常期望命中率至少在 80% 以上，优秀的情况下应达到 95% 甚至更高。
如果命中率长期低于 80%，则说明你的缓存系统可能“形同虚设”。大量的请求直接穿透到后端数据库，不仅拖慢了应用响应，更给数据库带来了巨大的压力，随时有被压垮的风险。此时，你需要立即审视你的淘汰策略、内存容量或业务逻辑是否存在问题。
面试加分项：规避大 Key 淘汰的“天坑”
最后，再分享一个面试必杀技。
当面试官追问：“如果淘汰一个包含数百万元素的 Hash 或 Zset，会发生什么？”
标准答案是：“会导致 Redis 主线程发生长时间阻塞，服务在几秒钟内都无法响应任何其他请求。”
紧接着，你需要立刻给出解决方案：“可以通过开启 lazyfree-lazy-eviction yes 这个配置来解决。开启后，当需要淘汰大 Key 时，Redis 会将真正的删除操作交由一个后台线程去异步执行，从而完美避免主线程阻塞。”
这样一套“发现问题 -> 分析原因 -> 解决问题”的组合拳打出来，面试官自然会明白，你不是一个只会纸上谈兵的理论派。
总结
现在，我们来回顾一下回答 Redis 内存淘汰问题的高手思路：
- Why：从
maxmemory和写命令的触发机制讲起，定下专业基调。 - What：用分类法清晰地讲透八大策略，并突出 LFU 的优势。
- How：给出明确的、基于业务场景的选型建议。
- Ops：最后落到运维监控，讲明白内存碎片率和缓存命中率这两个核心指标，并给出
lazy-free这样的实战调优大招。
掌握了这套逻辑，你不仅能从容应对面试，更能让你在实际工作中对 Redis 的使用得心应手。