没有“最适合”的策略，只有“最不伤业务”的策略；选错会导致缓存雪崩、写入失败或冷热数据错位，问题常在流量高峰暴露。
直接说结论：没有“最适合”的策略，只有“最不伤业务”的策略——选错会导致缓存雪崩、写入失败或冷热数据错位，而问题往往在流量高峰时才暴露。
noeviction 为什么常被误设为默认？
Redis 3.0+ 默认就是 noeviction，但它不是“安全兜底”，而是“拒绝服务”。一旦 maxmemory 被打满，所有写命令（SET、HSET、LPUSH 等）都会返回 (error) OOM command not allowed when used memory > 'maxmemory'。
- 它适合金融订单、分布式锁、核心配置等**绝对不可删、宁可写失败也不许丢数据**的场景
- 但如果你用 Redis 做通用缓存，又没配监控告警，
noeviction下内存满后应用层会持续收到写失败，可能引发级联超时 - 检查方式：
CONFIG GET maxmemory-policy；改之前务必确认maxmemory已设（CONFIG GET maxmemory返回非 0）
volatile-lru 和 allkeys-lru 的关键区别在哪？
两者都基于近似 LRU，但淘汰范围完全不同，直接影响你是否“误删重要数据”。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
volatile-lru只看带EXPIRE的键：适合缓存类数据（如用户 session、商品详情），而把持久化配置、计数器等无过期时间的键“保护”起来 -
allkeys-lru扫描所有键：适合纯缓存集群，且你**明确所有键都可被替换**；但如果混存了长期有效的 key（比如config:payment），它们也可能被踢出 - 陷阱：如果大量 key 没设 TTL，
volatile-lru可能根本淘汰不出空间，最终退化成noeviction行为 - 性能提示：
maxmemory-samples默认是 5，调高（如 10–20）可提升 LRU 近似精度，但增加 CPU 开销
LFU 类策略（allkeys-lfu / volatile-lfu）适合什么真实场景？
LFU 不是“更高级的 LRU”，它是另一种访问模式假设：**长期高频访问的数据，比刚访问过但只来一次的数据更有保留价值。**
-
allkeys-lfu适合长尾热点稳定、更新慢的场景，比如用户画像标签、城市天气缓存、静态资源元信息 -
volatile-lfu更谨慎：只在你给缓存加了 TTL 的前提下生效，避免误伤无 TTL 的系统 key - 注意 LFU 的“衰减”机制：计数器会随时间下降，防止历史热门数据长期霸占内存；但这也意味着突发流量带来的短期热度，可能撑不过几个小时
- 验证是否生效：用
OBJECT FREQ keyname查看当前 key 的 LFU 频次（仅限 Redis 4.0+）
volatile-ttl 和 random 类策略什么时候真能用？
别被名字迷惑——volatile-ttl 不是“智能清理”，而是“赶在过期前手动清”；random 类策略本质是“放弃治疗”。
-
volatile-ttl适合 TTL 设置差异极大、且你希望快速释放内存的场景，比如日志类 key（log:20260713:* → 1h TTL，log:20260701:* → 7d TTL），它优先踢掉马上要过期的，减少后台过期任务压力 -
volatile-random和allkeys-random几乎只用于测试环境或临时数据池；生产环境用它们，等于把淘汰决策交给掷骰子——缓存命中率波动大，且无法预测哪条数据会被删 - 一个硬提醒：Redis 的随机淘汰不是均匀分布，它依赖采样，样本量小（
maxmemory-samples默认 5）时，实际淘汰倾向仍受内部哈希分布影响
真正容易被忽略的点是：淘汰策略只在内存真正触顶时触发，而 maxmemory 是按 Redis 自身统计值判断的，不包含碎片内存、AOF 缓冲、复制积压缓冲等——这些额外开销会让实际可用内存比配置值少 10%～30%。线上务必留余量，并用 INFO memory 定期核对 used_memory、mem_fragmentation_ratio 和 evicted_keys 三个指标。
