Redis内存淘汰策略：业务场景下的选择逻辑

Redis作为高性能内存数据库，其内存资源是有限且宝贵的。当数据量增长超过maxmemory限制时，Redis需要依据预设的淘汰策略（eviction policy）决定哪些键被移除，以维持服务可用性。不同业务场景对数据完整性、访问时效性要求各异，盲目采用统一策略可能导致缓存命中率下降或关键数据丢失。本文梳理各策略的适用边界，帮助运维与开发人员按需配置。

主流淘汰策略分类与机制

Redis 6.x及7.x版本支持以下主要策略，可通过maxmemory-policy参数动态修改（CONFIG SET命令生效）：

• noeviction：不淘汰任何数据，当内存达到上限时，写入命令返回OOM错误。适用于数据不允许丢失的纯缓存场景，但需配合完善的监控与扩容机制。
• allkeys-lru：在所有键中按LRU（最近最少使用）近似算法淘汰。适合访问热点集中、数据陈旧性不敏感的通用缓存。
• allkeys-lfu：在所有键中按LFU（最不经常使用）近似算法淘汰，考虑访问频率而非仅最近时间。适合存在固定高频热点、低频冷数据的业务流量模型。
• volatile-lru：仅在设置了过期时间的键中执行LRU淘汰。适合同时存在长期数据与临时数据的场景，保护未设置过期时间的核心数据。
• volatile-lfu：在设置了过期时间的键中按LFU淘汰，兼顾频率维度。
• volatile-ttl：在过期键中优先淘汰剩余存活时间（TTL）最短的键。适合数据时效性强、越接近过期价值越低的场景，如验证码、短期会话。
• allkeys-random / volatile-random：随机淘汰，适用于数据访问概率均匀、无热点的场景，或作为兜底策略避免算法开销。

场景化选型建议

1. 电商商品详情缓存：allkeys-lfu

商品访问存在明显的长尾分布：少数爆款商品占据绝大多数访问量，大量长尾商品访问稀疏。LFU能确保高频率访问的爆款数据常驻内存，同时将冷门数据优先挤出，提升缓存命中率。若使用LRU，一次批量刷新的商品可能在短期内被误判为热点，造成热点数据被淘汰。

2. 用户Session会话存储：volatile-ttl 或 volatile-lru

Session通常设置过期时间，且配置了持久化存储作为后备。采用volatile-ttl可优先淘汰即将过期的会话，释放内存给新会话；若希望保留最近活跃会话，则volatile-lru更合适。未设置过期的永久用户资料键不会被误删，保证账号体系稳定。

3. 实时排行榜与计数统计：noeviction

排行榜或计数器数据通常不允许丢失，一旦写入，必须保留至业务主动删除。配置noeviction可在内存耗尽时直接阻断新写入，避免数据静默丢失。此时应配合内存监控实现提前扩容或数据降级。

4. 消息队列与异步任务：allkeys-random

当Redis用作轻量级队列（如List或Stream）且消息任务间无优先级差异时，随机淘汰不会显著影响整体执行进度。但需注意：淘汰可能丢弃未被消费的消息，业务应具备拉取失败重投机制。

5. 多业务混用实例：volatile-lru

一个Redis实例同时服务业务A（需长期保护数据）和业务B（可丢弃临时数据）。仅给业务B的键设置过期时间，采用volatile-lru即可在内存紧张时只淘汰临时数据，业务A的持久键不受影响。

配置与监控实践

1. 设置合理上限：maxmemory应低于物理内存并预留系统开销，建议为实例容量的70%-80%以留出缓冲。
2. 动态调整：通过CONFIG SET maxmemory-policy在线切换策略，无需重启，可在业务低峰期验证效果。
3. 监控关键指标：关注evicted_keys（淘汰键数）、expired_keys（过期键数）、misses与hits（缓存命中率），根据趋势评估策略是否适应当前流量。
4. 结合持久化：若启用AOF或RDB，淘汰仅影响内存副本，不影响持久化文件中的历史数据，但重启后会重新加载，需注意加载后的内存压力。

总结

Redis内存淘汰策略不存在绝对最优解，必须结合数据访问模式、丢失容忍度、过期键比例等因素综合判断。建议先在测试环境模拟峰值流量，对比不同策略下的命中率与淘汰量，再通过生产环境的灰度观察调优。合理的内存淘汰配置，能在有限资源下最大化业务价值。