Redis 2.8 与 6.0 淘汰策略底层不兼容，无法平滑升级，必须通过滚动替换+渐进切流实现整体切换：需重配 maxmemory-policy、maxmemory-samples 和 lazyfree-lazy-eviction，并验证 LFU 频次、evicted_keys 增速及缓存命中率。
不能直接“平滑升级内存淘汰策略”——2.8 和 6.0 的淘汰机制底层不兼容，必须配合版本升级整体切换，且需重配参数、验证行为差异。
Redis 2.8 与 6.0 的淘汰策略本质不同
2.8 只支持 volatile-lru、allkeys-lru 等 6 种淘汰策略，且实现是单线程扫描+近似 LRU（基于随机采样），没有 LFU 支持，也没有淘汰键的主动通知或统计追踪能力。6.0 新增了 volatile-lfu、allkeys-lfu，并重构了淘汰逻辑：引入更精确的 LFU 计数器、支持 maxmemory-samples 动态调优、淘汰前会检查 key 是否正在被客户端缓存（Tracking）引用。
关键差异点：
-
maxmemory-policy值在 2.8 中写volatile-ttl是合法的，在 6.0 中仍合法，但实际淘汰效果受新版本的过期键清理线程（active expiry）节奏影响更大 - 2.8 的
allkeys-lru在高并发下容易误删热点 key；6.0 的allkeys-lfu更稳定，但需要预热计数器（首次访问不计入频率） - 6.0 默认启用
lazyfree-lazy-eviction yes，淘汰大 value 不阻塞主线程；2.8 没有该机制，删 bigkey 会导致明显卡顿
升级前必须重配的三项核心参数
即使你只是想“沿用旧策略”，也不能直接复用 2.8 的配置文件。以下三项必须显式检查并设置：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
maxmemory-policy：2.8 默认是noeviction，6.0 仍是，但生产环境几乎都改成了allkeys-lru或allkeys-lfu；若保留volatile-lru，要确认所有业务 key 都设了 TTL，否则可能大量 key 不参与淘汰 -
maxmemory-samples：2.8 默认 5，6.0 默认也是 5；但实测中，6.0 下设为 10–20 能显著提升 LFU/LRU 准确率，尤其在 key 热度分布不均时 -
lazyfree-lazy-eviction：2.8 无此配置；6.0 必须设为yes，否则淘汰含大 Hash/List 的 key 会触发主线程停顿（>100ms），引发超时毛刺
淘汰行为验证不能只看 INFO memory
很多人升级后只检查 INFO memory | grep maxmemory 和 evicted_keys，这远远不够。真实淘汰是否符合预期，得结合业务语义验证：
- 用
redis-cli --scan --pattern "your:prefix:*" | head -n 1000 | xargs -I{} redis-cli object freq {}查 LFU 频次（仅 6.0+ 支持），确认高频 key 真的没被误删 - 在压测中监控
evicted_keys增速 +expired_keys增速 +keyspace_hits/keyspace_misses比值，三者突变不一致说明淘汰/过期逻辑被干扰 - 特别注意：6.0 对
volatile-ttl的实现更激进——它优先淘汰 TTL 剩余时间最短的 key，哪怕这个 key 刚被访问过；而 2.8 是“TTL 接近 0 且未访问”，行为不可简单映射
真正的平滑路径只有“滚动替换+渐进切流”
所谓“策略平滑升级”本质是伪命题。你无法让 2.8 实例突然理解 6.0 的 LFU 计数器，也无法让 6.0 实例按 2.8 的采样逻辑做淘汰。唯一可行路径是：
- 先搭一套 Redis 6.0 集群（或主从），配置好目标淘汰策略和
lazyfree参数 - 用
redis-shake或redis-cli --rdb同步全量数据（注意：RDB 中不包含 LFU 频次，所以新集群启动后所有 key 的 freq=0，需靠流量自然重建） - 通过客户端代理（如 Twemproxy）或应用层灰度开关，逐步将读写流量切到 6.0；期间密切观察
evicted_keys增速是否异常、cache hit rate 是否骤降 - 切流完成后，旧 2.8 实例下线，不再共存
跨版本混跑集群（比如 2.8 主 + 6.0 从）不可行——淘汰决策由各节点独立执行，没有协调机制，会导致同一份数据在不同节点上被不同策略处理，最终一致性完全失控。
