redis 7.0未新增淘汰策略类型，仍为8种，改进在于底层行为调优和默认配置收紧：maxmemory-samples建议调高至10或15以提升精度；lazyfree-lazy-eviction默认启用异步淘汰但需防oom；volatile-*策略无过期key时退化为noeviction且日志提示更明确；allkeys-lru需满足持续访问、预留20%内存余量、禁用lazyfree-lazy-eviction才可控；aof重写引发内存暴增需调低auto-aof-rewrite-percentage至70左右并启用activedefrag；命中率根本取决于数据结构优化（如hash）、ttl随机化及冷热分离部署。

Redis 7.0的淘汰策略本身没有新增类型

Redis 7.0 没有增加新的 maxmemory-policy 类型，仍维持 8 种策略（noeviction、volatile-lru、allkeys-lfu 等）。所谓“改进”其实是底层行为调优和默认配置收紧，而非策略逻辑变更：

• maxmemory-samples 默认值仍为 5，但文档更明确建议：写入密集场景可设为 10 或 15 来提升 LRU/LFU 的淘汰精度，代价是轻微 CPU 上升
• lazyfree-lazy-eviction 默认为 yes，意味着淘汰动作可能异步化——这在高吞吐下能降低主线程延迟，但若 used_memory_rss 持续逼近物理内存上限，异步释放可能跟不上申请速度，反而引发 OOM command not allowed when used memory > 'maxmemory'
• volatile-* 策略在无过期 key 时会静默退化为 noeviction，7.0 对该行为的日志提示更早、更明确（INFO 命令输出中 evicted_keys 长期为 0 且 rejected_commands 上升，就是退化信号）

allkeys-lru 是缓存场景最可控的选择，但依赖两个前提

很多人误以为设了 allkeys-lru 就万事大吉。实际上它只在以下条件满足时才真正“可预测”：

• 业务写入后必须有持续访问——否则 LRU 链表无法建立有效热度排序，新写入一批 key 后集体静默（如预热商品页），LRU 会把它们全当成冷数据优先踢掉
• maxmemory 必须预留至少 20% 物理内存余量，例如服务器有 64GB 内存，maxmemory 不应设超过 50GB；否则内存打满瞬间触发大批量淘汰，CPU 和延迟毛刺明显
• 禁用 lazyfree-lazy-eviction（即设为 no）——AOF 重写或突发写入期间，同步淘汰比异步更可控，避免后台任务堆积拖慢响应

AOF重写期间内存暴增，不是淘汰策略的问题，而是配置联动失效

BGREWRITEAOF 本身不修改数据，但它 fork 子进程 + 维护 aof_rewrite_buf 缓冲区，会显著拉升 used_memory_rss。此时若 maxmemory 设置偏紧，allkeys-lru 会疯狂淘汰，形成“写入→内存涨→淘汰→CPU 升→延迟高→更多写入重试”的正反馈循环。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 关键修复点不是换策略，而是调低 auto-aof-rewrite-percentage：当 used_memory / maxmemory > 0.7 时，应从默认 100 降至 70 左右，让重写更早、更轻量地触发
• auto-aof-rewrite-min-size 也要同步下调，SSD 环境建议设为 32mb，避免单次重写处理过多命令
• 检查 mem_fragmentation_ratio：若长期 > 1.5，说明内存碎片严重，需开启 activedefrag yes，否则 used_memory 看似不高，used_memory_rss 却已逼近上限

真正影响命中率的，常是数据结构和写入模式，不是淘汰策略本身

淘汰策略只是“兜底手段”，而缓存命中率取决于你存什么、怎么存、何时删：

• 用 HASH 存对象字段，比拆成多个 STRING 键节省 5–10 倍内存；但要配好 hash-max-listpack-entries（建议 512）和 hash-max-listpack-value（建议 64），否则自动转哈希表，内存开销翻倍
• 避免批量设置相同 TTL：比如所有商品缓存统一设 EX 3600，会导致 volatile-ttl 在整点集中清空，雪崩风险极高；应改用随机偏移，如 EX 3600 + random(0, 600)
• 冷热分离：用户 session 类数据用 volatile-lru，配置中心类元数据用 noeviction + 单独实例，别混在一个 Redis 里——混合策略会让淘汰行为不可控

淘汰策略选型容易，但让它稳定生效需要看内存水位、AOF节奏、数据结构三者是否咬合。很多线上问题不是策略错了，而是 maxmemory 设得像贴身内衣一样紧，又忘了 aof_rewrite_buf 这个隐形吃内存大户。