一、核心策略对比表
策略名称 | 淘汰逻辑 | 优点 | 缺点 | 适用场景 |
LRU | 淘汰最久未访问的数据 | 实现简单，适应热点数据 | 可能误删近期访问但低频数据 | 常规业务（默认推荐） |
LFU | 淘汰访问频率最低的数据（时间 + 次数） | 精准区分冷热数据 | 实现复杂，内存占用略高 | 数据访问频率差异大的场景 |
FIFO | 淘汰最早写入的数据 | 实现简单，保证时效性 | 无法应对突发访问 | 日志、短期会话等时效性要求高 |
随机淘汰 | 随机删除数据 | 无计算开销 | 命中率不稳定 | 测试环境或数据分布均匀场景 |
仅淘汰过期键 | 仅处理已过期数据 | 避免误删关键数据 | 需依赖合 |
二、策略细节解析
1.LRU（Least Recently Used）
- 实现：Redis 使用 近似 LRU（随机采样 + 淘汰），通过配置 maxmemory-samples 控制采样数量（默认 5）。
- 示例：用户行为记录、商品详情页缓存。
- 优化：结合 volatile-ttl 优先淘汰即将过期的键。
2.LFU（Least Frequently Used）
- 实现：维护访问次数（计数器）和时间衰减，Redis 2.8+ 支持。
- 参数：lfu-log-factor：控制频率计数的衰减速度（默认 10）。lfu-decay-time：时间衰减单位（分钟，默认 1）。
- 适用：用户高频访问但偶尔冷启动的场景（如电商热门商品）。
3.FIFO
- 替代方案：使用 List 结构存储数据，手动维护顺序。通过脚本定期删除最旧的键。
- 局限：无法利用 Redis 原生淘汰机制，需额外开发。
4.仅淘汰过期键
- 子策略：volatile-ttl：优先淘汰剩余存活时间最短的键。volatile-lru/volatile-lfu：在过期键中应用 LRU/LFU。
- 建议：对需要长期保留的键不设置过期时间，避免被淘汰。
三、选择策略的 3 个维度
- 数据特征：冷热分明 → LRU/LFU。时效性强 → FIFO 或 volatile-ttl。均匀分布 → 随机淘汰。
- 业务优先级：不允许丢失 → 仅淘汰过期键 + 持久化。可接受部分丢失 → LRU/LFU。
- 性能成本：LFU 比 LRU 内存占用高约 10%，但命中率更优。避免频繁触发淘汰（如设置 maxmemory-policy noeviction 强制报错）。
四、监控与调优
- 关键指标：
- bash
redis-cli info stats | grep evicted_keys # 查看淘汰次数
redis-cli info memory | grep maxmemory # 内存使用情况调优示例：conf
maxmemory 1gb
maxmemory-policy allkeys-lfu
maxmemory-samples 10 # 提高 LRU 精准度
lfu-log-factor 5 # 加快低频数据淘汰五、总结建议
- 首选 LFU：若业务数据访问频率差异明显，优先使用 allkeys-lfu。
- 结合过期时间：对短期数据设置合理 TTL，降低淘汰压力。
- 监控 + 实验：通过 redis-cli monitor 观察淘汰行为，调整策略参数。
如需保留特定数据，可使用 BITFIELD 或设置无过期时间（EXPIRE key -1）。