Redis内存淘汰策略共8种，已自6.0起稳定支持，包括allkeys-lfu、volatile-ttl等；官方明确不再新增策略，优化关键在于根据数据特征精准选型、合理配置maxmemory及调参，而非等待版本更新。
Redis内存淘汰策略没有“未来优化方向”这个说法——它已经具备生产级成熟度，当前所有策略（allkeys-lfu、volatile-ttl等）都是稳定可用的，所谓“优化”不是等新功能，而是根据业务数据特征做精准选型和调参。
为什么maxmemory-policy不能靠“等更新”解决
Redis从6.0起就已完整支持8种淘汰策略，包括allkeys-lfu和volatile-lfu这类基于访问频次的算法。源码中淘汰逻辑固化在evict.c，不依赖外部AI或动态学习模块。所谓“未来优化”，实际是运维层面的事：
- 策略本身不会新增——Redis官方明确表示不再增加新淘汰策略，重点转向监控与诊断工具完善
-
LFU衰减周期、LRU采样数等参数可调，但需实测验证，不是版本升级自动变好 - 真正瓶颈常不在策略算法，而在大Key、内存碎片或
maxmemory设得不合理
allkeys-lfu比allkeys-lru更值得优先尝试
如果你的缓存存在明显热点（比如首页商品、用户会话），allkeys-lfu通常比allkeys-lru更能保住高频数据。但要注意：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
LFU计数器有衰减机制，默认每分钟右移1位（lfu-decay-time 1），长期不访问的热数据会“降权”，避免僵化 - 刚写入的数据
counter初始值为5，不是0，防止新数据被立刻淘汰 - 用
OBJECT FREQ命令可查单个key的当前频次，但频繁调用会影响性能，仅用于抽检
容易被忽略的三个实操细节
配置写对不等于效果到位，这三个点出错会导致策略形同虚设：
-
maxmemory必须显式设置，否则默认为0（不限制），maxmemory-policy根本不会触发 - 用
INFO memory看mem_clients_normal和mem_clients_slaves，确认没被客户端缓冲区吃掉大量内存 -
volatile-ttl只对设置了EXPIRE的key生效，如果全用SET没配过期时间，该策略等价于noeviction
真正要花时间的地方，是用redis-cli --bigkeys扫出大Key、用MEMORY USAGE定位膨胀字段、再结合MONITOR观察访问模式——算法再好，喂进去的是噪声数据，结果就是随机淘汰。
