Redis淘汰策略本身非免费操作，不同算法CPU开销差异显著：allkeys-random几乎无开销，allkeys-lfu因维护频次计数器和衰减逻辑实测QPS下降8%～12%，volatile-ttl在过期键占比高时扫描开销上升；淘汰仅在写入触发且内存不足时发生，主要拖慢写请求延迟，对读性能基本无影响。
淘汰策略本身会增加CPU开销，但影响程度取决于具体算法
Redis在内存达到maxmemory后触发淘汰时，不是“免费操作”。不同策略的计算成本差异明显：allkeys-random几乎无开销，而allkeys-lfu需维护每个key的访问频次计数器和衰减逻辑，实测QPS下降约8%～12%（基于Redis 7.2，4核16GB实例，10万key规模）。volatile-ttl虽不统计访问，但每次都要扫描过期键的剩余TTL，当过期键占比高时，CPU占用会上升。
关键点在于：淘汰动作只在写入触发、且内存不足时发生，并非持续运行。所以它对读性能基本无影响，主要拖慢的是写请求的响应延迟——尤其是批量写入场景下，可能因连续淘汰导致单次SET耗时突增。
-
noeviction看似“零开销”，但实际会让写失败（返回(error) OOM command not allowed when used memory > 'maxmemory'.），业务需自行重试或降级，反而更难控制 -
allkeys-lru采用近似LRU（随机采样5个key比对空闲时间），平衡了精度与速度，是多数场景的默认推荐 - 如果用
volatile-lfu，必须确认所有热数据都设置了EXPIRE，否则没设过期时间的key永远不参与淘汰，可能导致内存被冷数据占满
命中率不是越高越好，要看访问模式是否匹配策略假设
高命中率的前提是淘汰逻辑和真实访问分布一致。比如用allkeys-lfu却面对的是“长尾访问”场景（大量key只访问1～2次），LFU会错误保留低频key，把真正高频的挤出去；反过来，用allkeys-lru处理突发热点（如秒杀商品），LRU容易把刚爆火的key当成“新数据”留下，但若它之后不再访问，又会卡在缓存里浪费空间。
验证方式很简单：通过INFO stats看keyspace_hits和keyspace_misses，算出实时命中率；再结合redis-cli --bigkeys和MEMORY USAGE确认大key是否干扰了采样精度。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 电商详情页缓存适合
volatile-lru：商品页普遍设TTL，且访问有明显时间局部性 - 用户feed流推荐适合
allkeys-lfu：少数热门内容反复刷屏，其他内容访问稀疏 - 验证码/临时token类数据优先用
volatile-ttl：它们天然按到期顺序失效，无需额外统计
配置不当比选错策略更危险
很多人调完maxmemory-policy就以为万事大吉，其实几个隐藏参数会彻底改变行为：
-
maxmemory-samples默认是5，即每次淘汰只随机检查5个key。压测发现，把它提到10能提升allkeys-lru命中率约6%，但CPU使用率同步上升15% -
lfu-log-factor和lfu-decay-time共同控制LFU计数器衰减速度。factor太小（如1）会导致频次区分度低；太大（如100）会让旧访问长期影响决策，实际建议保持默认值10 - 没配
activedefrag yes时，长期运行后内存碎片率mem_fragmentation_ratio超过1.5，即使还有空闲内存，Redis也可能提前触发淘汰
真正影响性能的往往是淘汰前的“过期键堆积”
淘汰策略管的是“内存不够时删谁”，而“过期键不及时删”才是更隐蔽的性能杀手。Redis用惰性删除+定期删除双机制清理过期key，但如果hz值太低（默认10），在高写入场景下，过期key可能堆积数分钟才被扫到，导致used_memory虚高、淘汰提前触发。
生产环境建议把hz调到20～50之间，配合active-expire-effort 3（定期删除更积极），能减少过期键滞留。但这会多占1%～3% CPU，需要在监控中观察expired_keys指标是否稳定下降。
最常被忽略的一点：淘汰策略只作用于主库。如果你用Redis做读写分离，从库不执行淘汰，used_memory可能持续上涨却不报警——得靠INFO memory定时采集所有节点数据来发现。
