redis 5.0与6.0内存淘汰策略无实质性差异，均支持相同的8种maxmemory-policy，语义、触发逻辑、采样机制（默认maxmemory-samples=5）及lru/lfu实现方式完全一致；6.0引入的多线程i/o仅提升网络吞吐，不改变淘汰行为本身。
Redis 5.0 和 6.0 的内存淘汰策略在行为、实现细节和默认配置上完全一致，maxmemory-policy 支持的 8 种策略没有新增或删减，也不因版本升级自动变更——选错策略不是版本问题，而是配置或场景误判。
Redis 5.0 vs 6.0 淘汰策略有无差异？
没有实质性差异。从 Redis 4.0 引入 volatile-lfu 和 allkeys-lfu 开始，到 5.0、6.0，所有 8 种策略（noeviction、volatile-lru、allkeys-lru、volatile-lfu、allkeys-lfu、volatile-ttl、volatile-random、allkeys-random）的语义、触发逻辑、采样机制（如 maxmemory-samples 默认为 5）、近似 LRU/LFU 实现方式均未改动。
唯一“变化”是 Redis 6.0 默认启用了多线程 I/O（io-threads），但它只影响网络读写吞吐，不改变淘汰策略本身的执行流程或判定结果。
-
CONFIG GET maxmemory-policy在 5.0 和 6.0 下返回值相同，默认仍是noeviction -
INFO memory中的mem_evicted_keys计数逻辑一致，统计的是实际被策略删除的 key 数量 - 淘汰仍发生在写命令执行路径中（如
SET、HSET），且是同步阻塞的——这点在两个版本里都可能导致延迟毛刺
为什么线上看到 6.0 淘汰更“激进”或更“不准”？
这不是策略本身变了，而是 6.0 的多线程 I/O + 更高并发写入放大了原有机制的副作用：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 当开启
io-threads 4后，并发写请求增多，触发淘汰的频率更高，容易让人误以为“6.0 更爱删数据” -
maxmemory-samples仍默认为 5，采样量小 → 近似 LRU/LFU 准确度有限 → 在高吞吐下，allkeys-lru可能淘汰掉刚被访问过的 key，现象像“策略失灵” - 6.0 对 AOF rewrite 和 RDB fork 的内存预估更保守，偶尔导致
used_memory短暂冲高，提前触发淘汰
验证方法：停用多线程（io-threads 1），保持 maxmemory-samples 10，再对比淘汰行为——基本一致。
生产环境怎么选策略？看数据有没有 TTL
核心判断依据不是 Redis 版本，而是你的 key 是否普遍带过期时间（TTL）。这个决定比“用 5 还是 6”重要十倍：
- 如果你的业务大量使用
SET key val EX 3600（比如 session、token、临时计算结果）→ 优先考虑volatile-*系列：volatile-lru或volatile-lfu。它们只动“临时数据”，保护你没设 TTL 的配置类 key - 如果你所有 key 都是缓存，且统一用
EX或PX控制生命周期 → 直接用allkeys-lru或allkeys-lfu。更简单，命中率通常更高 - 如果部分 key 绝对不能删（如分布式锁的 guard key、基础配置），又必须用缓存 → 必须配
volatile-ttl或volatile-lru，并确保只有缓存 key 设 TTL - 别用
noeviction做缓存——它会让SET返回(error) OOM command not allowed when used memory > 'maxmemory'，前端直接报错
容易被忽略的三个实操点
无论 5.0 还是 6.0，这三个细节常被跳过，但直接影响淘汰效果：
-
maxmemory必须显式设置，否则maxmemory-policy不生效（Redis 启动时会打印WARNING: You have specified a maxmemory value...提示你） -
allkeys-lfu和volatile-lfu依赖访问频次计数器，该计数器有衰减机制（默认 1 分钟衰减一次），若 key 访问间隔远超衰减周期，LFU 行为会退化成接近随机 —— 此时不如换回 LRU - 淘汰不是“删完就完”，被删 key 的内存释放存在延迟：大 value（如 >1MB 的 string 或 zset）的释放可能跨多个事件循环，
INFO memory中的used_memory不会立刻下降，但新写入已可进行
