Redis 6.0淘汰机制更主动：以used_memory为唯一触发依据，提前采样淘汰；LRU/LFU采样更激进（samples=5），新增LFU调参，并在fork时主动触发淘汰应对COW压力。
不是淘汰“速率”变快了，而是淘汰触发更及时、更贴近真实内存压力。Redis 5.0 到 6.0 的淘汰行为变化，本质是 maxmemory 判断逻辑和后台淘汰线程协作方式的调整，不是单纯把“删得更快”当优化目标。
maxmemory 的实际生效点变了
Redis 5.0 的 maxmemory 仅作用于数据本身（used_memory_dataset），但忽略了一大块开销：对象头、key 字符串、连接缓冲区、AOF rewrite 缓冲等——这部分归在 used_memory_overhead 里。5.0 在触发淘汰前，会等到 used_memory（含 overhead）明显超出 maxmemory 才动手，导致“明明设了 2GB，结果 RSS 已到 3.1GB 才开始删”。
Redis 6.0 改为以 used_memory 为唯一淘汰触发依据，且更早介入：一旦接近阈值（比如 95%），就主动启动采样淘汰，避免突增写入直接打穿上限。
LRU/LFU 淘汰采样逻辑更激进
Redis 6.0 默认启用 maxmemory-samples 5（5.0 是 3），且在每次事件循环中尝试更多轮次的随机 key 采样与淘汰判断。这不是暴力删，而是：
• 更频繁地检查过期 key 是否可顺手清理（惰性删除 + 定期删除协同更强）
• 对 LFU 策略，新增了 lfu-log-factor 和 lfu-decay-time 可调参数，让冷热识别更灵敏，避免“伪热点 key 长期霸占内存”
• 淘汰决策不再只看单次采样结果，而是结合最近几次采样趋势做加权判断
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
后台线程参与释放压力（尤其在 AOF rewrite 或 RDB fork 时）
Redis 6.0 引入更积极的后台内存回收机制：
• 当执行 fork()（如 BGSAVE 或 AOF rewrite）时，子进程会共享父进程页表，但写时复制（COW）会导致物理内存翻倍增长。6.0 在检测到 COW 内存飙升时，会主动触发一轮强制淘汰，提前腾出空间，避免 used_memory_rss 突然飙高被 OOM Killer 杀掉
• 这个动作对客户端不可见，但你在 INFO memory 里会看到 mem_allocator（如 jemalloc）的碎片率短暂下降、evicted_keys 计数跳升
• 5.0 完全依赖主线程处理，遇到大 fork 场景只能硬扛，直到写入失败
真正容易被忽略的是：这个“淘汰变快”现象，在业务写入模式剧烈波动（例如秒杀预热期大量 set + ttl）或启用了 activerehashing yes 的场景下最明显。它不是性能提升，而是内存水位控制策略从“被动兜底”转向“主动削峰”——代价是淘汰 CPU 开销略增，但换来了更稳定的 P99 延迟和更低的 OOM 风险。
