必须用noeviction时，是当业务写入不可中断且任何数据丢失都不可接受，如金融交易流水、审计日志等场景；它不淘汰数据，仅报错，要求应用层捕获OOM错误并降级或告警，同时需提前规划内存水位与监控。
什么时候必须用 noeviction？
当业务写入行为不可中断、且任何数据丢失都不可接受时，noeviction 是唯一安全选项。比如金融交易流水、审计日志、核心配置同步等场景，一旦 Redis 拒绝写入，应用层必须能捕获 OOM command not allowed when used memory > 'maxmemory' 错误并降级或告警——否则会静默失败。
它不淘汰、不释放、不妥协，只报错。这意味着你必须提前规划好内存水位（比如 maxmemory 设为物理内存的 70%），并配合监控（如 used_memory_peak_human、mem_fragmentation_ratio）做主动扩容或归档，不能指望 Redis 自己“想办法”。
volatile-* 类策略适合什么数据结构？
只对带 EXPIRE 的 key 生效，本质是“有明确生命周期”的缓存数据。典型包括：session、token、验证码、临时查询结果。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
注意陷阱：
– volatile-ttl 看似“智能”，但容易在批量写入短 TTL 数据（如每秒生成千条 60s 过期的临时任务 ID）时，集中淘汰即将过期的 key，导致缓存命中率骤降；
– volatile-lru 和 volatile-lfu 要求你确保所有该淘汰的数据确实设置了过期时间——漏设 EXPIRE 就等于“免疫”淘汰，可能把内存撑爆；
– 如果部分 key 忘记设过期时间，又混用了 allkeys-*，反而会误伤长期有效的业务元数据。
allkeys-lfu 和 allkeys-lru 怎么选？
关键看访问模式是否稳定：
– allkeys-lru 对突发流量友好：新写入的热数据立刻进入“最近使用队列”，旧冷数据即使访问过一次也很快滑出；适合新闻热点、秒杀商品页等时效性强的缓存；
– allkeys-lfu 更适合长尾稳定型服务：比如用户画像标签、地域偏好配置，访问频次低但长期有效，lfu-log-factor 和 lfu-decay-time 参数要调得足够宽松（默认值常偏激进），否则低频但关键的 key 会被快速计数衰减掉。
实测中，allkeys-lfu 在启用了 maxmemory-samples 10（默认 5）后，淘汰精度提升明显，但 CPU 使用率会上浮 3%~5%，需权衡。
为什么 random 类策略不是“兜底”，而是“危险信号”？
volatile-random 和 allkeys-random 不解决“哪些该留”，只解决“先删谁”。它们在以下情况才合理：
– 你明确知道所有 key 的价值完全均等（比如纯临时计算中间结果）；
– 或作为压测/故障演练时的临时策略，验证下游能否容忍随机丢数据；
– 或配合自定义淘汰逻辑（如 Lua 脚本预筛选）作辅助手段。
生产环境直接配 random，等于放弃缓存语义——你不再控制数据留存逻辑，而把决策权交给伪随机数生成器。一旦出现缓存雪崩或命中率断崖下跌，排查起来毫无线索。
volatile-* 策略“漏掉”；再比如 lfu-decay-time 调小了，高频 key 可能被误判为冷数据——这些细节没对齐，策略再“先进”也白搭。 
