缓存淘汰策略与内存管理：LRU、LFU、TTL、内存碎片处理

缓存淘汰策略与内存管理是分布式缓存的核心机制，直接影响缓存命中率、内存利用率和系统稳定性。面试中常围绕 LRU/LFU 实现原理、TTL 过期策略、内存碎片治理等展开深度考察，需要求职者从原理到工程实践具备系统性认知。以下通过对比表格、回答框架图、典型问答及真实项目模板，帮助你构建结构化的面试表达体系。

缓存淘汰策略核心对比

面试问题：请结合数据结构，详细说明 LRU 缓存的实现原理，并分析其在 Redis 和 Caffeine 中的差异。

面试官考察点：

• 是否理解哈希表 + 双向链表协同工作的细节（O(1) 访问与淘汰）
• 能否区分「严格 LRU」与「近似 LRU」在不同中间件中的工程取舍
• 是否关注过 Window-TinyLFU 等更优的混合策略

回答框架：

1. 原理简述：哈希表保证 O(1) 查找，双向链表维护访问顺序，访问时节点移至头部，淘汰时移除尾部。
2. Redis 实现：近似 LRU，通过采样 key 淘汰，避免维护全量链表，降低内存开销。
3. Caffeine 实现：Window-TinyLFU，结合 LRU 与 LFU 优势，抵抗扫描污染且保持高频数据。
4. 工程取舍：严格 LRU 准确但内存高，近似 LRU 节省内存但可能淘汰热 key。

简短示例回答：

LRU 基于哈希表 + 双向链表，访问时节点移至头部，淘汰尾部。Redis 采用近似 LRU，通过采样 5～15 个 key 淘汰，减少内存占用；Caffeine 使用 Window-TinyLFU，结合频率与新鲜度，抗扫描污染更好。项目中我根据缓存大小和访问分布选择实现，并监控命中率调优采样数。

可能追问：

• Redis 的 maxmemory-policy 有哪些？allkeys-lru 与 volatile-lru 如何选择？
• Caffeine 的 Window-TinyLFU 中「Window」和「Main」两部分如何协作？
• 如果让你实现一个内存受限的严格 LRU，你会用哪种数据结构？

面试问题：在什么场景下 LFU 优于 LRU？实现 LFU 时如何解决频次衰减和缓存预热问题？

面试官考察点：

• 是否理解 LFU 在「长尾热点」场景下的优势
• 能否识别频次衰减（aging）和预热（warm-up）两大工程痛点
• 是否了解 Redis LFU 的 Morris counter 和衰减因子设计

回答框架：

1. 场景对比：LRU 适合近期访问热点，LFU 适合访问频率稳定、有长尾热点的场景（如推荐系统）。
2. 频次衰减：LFU 计数器需随时间衰减，否则历史高频 key 永远不被淘汰；Redis 使用 Morris counter + 衰减因子。
3. 缓存预热：新 key 频次低易被淘汰，可设置初始频次或结合 LFU + LRU 混合策略。
4. 工程实践：Caffeine 的 Window-TinyLFU 通过「频率信号 + 新鲜度窗口」同时解决衰减和预热。

简短示例回答：

LFU 适合访问频率稳定、长尾明显的场景，如商品详情页。频次衰减通过 Morris counter + 衰减因子实现，避免历史高频 key 永久保留。预热问题可给新 key 设置初始频次或采用混合策略。我在推荐系统中使用 Caffeine 的 Window-TinyLFU，预热时间从 5 分钟缩短至 30 秒。

可能追问：

• Redis LFU 的 lfu-log-factor 和 lfu-decay-time 如何配置？
• Morris counter 的原理是什么？它如何节省内存？
• 如果缓存访问模式在一天内动态变化，你如何自适应选择策略？

面试问题：Redis 的过期键删除策略有哪些？生产环境中如何处理内存碎片？

面试官考察点：

• 是否理解惰性删除与定期删除的协作机制与各自局限
• 能否给出内存碎片率（mem_fragmentation_ratio）的合理阈值与治理方案
• 是否经历过内存碎片导致 OOM 或延迟飙升的真实案例

回答框架：

1. TTL 删除策略：惰性删除（访问时检查）+ 定期删除（每秒 10 次采样淘汰）+ 内存淘汰策略兜底。
2. 内存碎片成因：Redis 分配粒度、键值频繁修改、不同大小 key 混存。
3. 碎片治理：开启 activedefrag（hot&warm 碎片整理），配置合理阈值；低峰期重启或迁移槽位。
4. 监控指标：mem_fragmentation_ratio > 1.5 需关注，> 2.0 必须介入。

简短示例回答：

Redis 使用惰性删除 + 定期删除协作，定期删除每秒 10 次采样 20 个 key 清理过期键。内存碎片率超过 1.5 时开启 activedefrag，配置 100MB 碎片阈值和 10% 碎片率阈值。曾在订单系统遇到碎片率达 2.3 导致延迟飙升，通过低峰期迁移槽位和调整 maxmemory 策略解决。

可能追问：

• activedefrag 的 CPU 开销如何控制？哪些场景不适合开启？
• 定期删除的「每秒 10 次」是硬编码吗？如何优化？
• Redis 4.0 之前如何处理碎片？有什么替代方案？

项目名称

电商大促缓存分层治理与内存碎片优化

业务背景

618 大促期间，商品详情页缓存命中率从 95% 骤降至 60%，TP99 延迟从 5ms 飙升至 120ms。内存碎片率超过 30%，GC 暂停时间达 500ms，数据库连接池多次被打满。

规模指标

• QPS：10万+
• 缓存节点：120 个 Redis Cluster 节点
• 总内存：2TB
• 日请求量：8亿+

技术栈

Redis 6.x Cluster + Caffeine 3.x + Sentinel + JMX + 自研监控大盘

核心难点

1. LRU 污染严重：大促秒杀流量扫描大量一次性 key，LRU 淘汰了真实热点，命中率断崖式下降。
2. 内存碎片率失控：频繁写入和过期导致碎片率超 30%，单节点内存利用率仅 70%。
3. TTL 雪崩风险：大量 key 设置相同过期时间，导致定期删除压力集中，CPU 飙升至 90%。

面试高频追问

• Q：你用什么指标判断 LRU 污染？如何区分「扫描流量」和「真实热点」？
  可迁移话术：通过缓存命中率 + 访问频次分布（P99/P999 key 访问量）+ 业务特征（是否来自爬虫/批量任务）综合判断，结合 Caffeine 的 Window-TinyLFU 的频率信号过滤扫描。
• Q：内存碎片率 30% 是如何测量的？activedefrag 配置了哪些参数？
  可迁移话术：通过 INFO memory 的 mem_fragmentation_ratio 监控，activedefrag 配置 active-defrag-threshold-lower 10 和 active-defrag-ignore-bytes 100MB，低峰期触发。
• Q：TTL 雪崩你怎么解决的？
  可迁移话术：对同类 key 的 TTL 添加随机偏移（±30%），并拆分到不同 Redis 节点；同时将过期检查与业务请求分离，避免定期删除阻塞。

可迁移回答话术