noeviction策略在生产环境基本不可用，因其直接拒绝所有写入命令并返回OOM错误，导致依赖缓存写的业务（如会话更新、计数器）立即中断；仅适用于完全不允许数据丢失且具备实时告警+人工扩容能力的离线分析类实例。
noeviction 策略为什么在生产环境基本不可用
它不是“保守”，而是直接拒绝所有写入命令，返回 (error) OOM command not allowed when used memory > 'maxmemory'。读操作照常，但任何 SET、HSET、LPUSH 都失败。业务只要依赖缓存写入（比如会话更新、计数器累加），就会立刻报错中断。
适用场景极窄：仅限完全不允许数据丢失、且有外部强干预机制（如实时告警+人工扩容）的离线分析类 Redis 实例。日常 Web 服务、API 缓存、用户状态存储等都应排除。
- 不解决内存增长问题，只把压力甩给上层
- 监控指标容易误判——
used_memory_peak持续逼近maxmemory，但evicted_keys始终为 0，掩盖真实瓶颈 - 主从复制下，从节点也会同步拒绝写入行为，可能引发复制中断或不一致
volatile-* 类策略对过期键管理的实际约束
像 volatile-lru、volatile-ttl 这类策略，只在 expires 字典里找目标淘汰，完全忽略没设 EX / PX 的 key。这意味着：
- 如果你混用了带 TTL 和永久 key（比如配置项用
SET config:timeout 30不加过期），那永久 key 永远不会被选中淘汰，哪怕占了 90% 内存 -
volatile-ttl看似“智能”，实则容易误伤：一个刚写入、TTL 剩余 1 秒的临时 token，比一个已存在 23 小时、TTL 剩余 61 分钟的用户 session 更早被淘汰 - 当过期 key 占比很低（
db->expires->size / db->dict->size < 0.1），Redis 抽样效率骤降，实际淘汰速率跟不上写入速度，很快又触发 OOM
这类策略只适合「几乎全部 key 都设了 TTL」的纯缓存场景，比如短时效会话、验证码、临时任务状态。
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
allkeys-lfu 在热点数据场景下的隐性代价
allkeys-lfu 确实能保留高频访问 key，但它的频率统计不是免费的：
- 每个 key 的
lru字段被复用为 24 位 LFU 计数器 + 8 位衰减时间戳，访问时需原子更新，高并发下锁竞争明显高于 LRU - 衰减逻辑（默认每分钟对计数器右移）由后台定时任务触发，若
server.hz被调低（比如设为 1），衰减延迟加剧，冷 key 可能长期滞留 - LFU 对“突发流量”不敏感：一个突然爆火的 key，初始计数低，可能在还没涨起来前就被淘汰；而 LRU 至少能靠最近一次访问保命
建议仅在明确存在稳定长尾访问模式（如商品详情页缓存，TOP 100 商品日均访问万次，其余百万商品日均不到 1 次）时启用，并搭配 lfu-log-factor 和 lfu-decay-time 调优。
allkeys-random 和 volatile-random 的真实定位
它们不是“随便删”，而是明确放弃访问模式假设，用最小开销换确定性响应延迟：
- 不维护 LRU/LFU 元数据，不采样判断，直接哈希随机取 key 删除，CPU 开销趋近于零
- 适合写入密集、读取无强局部性、且能容忍缓存命中率波动的场景，比如日志聚合中间层、实时指标暂存（
INCRBY stats:hourly:2026052818 1类 key） - 注意：
random类策略无法防止内存缓慢爬升——如果新 key 持续写入且不淘汰旧 key（因抽样未命中），仍可能耗尽内存；必须确保写入节奏与淘汰能力匹配
真正关键的是：这些策略本身不解决“为什么内存涨得快”，只决定“涨满了删谁”。排查 mem_allocator、大 value、未清理的集合、客户端连接泄漏，比调策略更优先。
