直接查evicted_keys指标可确认淘汰是否触发，其非零值表明策略已生效；需结合used_memory与maxmemory比值判断是否频繁触限，若evicted_keys长期为0但内存接近阈值，则可能是noeviction策略或无key可淘汰。
怎么看淘汰是否真在起作用
直接查 evicted_keys 指标。它统计自 Redis 启动以来被主动淘汰的 key 总数，值非零说明策略已触发。配合 used_memory 和 maxmemory 对比，能确认是否频繁踩到阈值边界。如果 evicted_keys 长期为 0，但 used_memory 接近 maxmemory，大概率是用了 noeviction 或写入量根本没触达阈值。
为什么 evicted_keys 突增却没缓解内存压力
常见于 volatile-lru 或 volatile-ttl 这类只作用于带过期时间的 key 的策略。如果当前库中大量 key 没设 expire，哪怕内存爆满，这些策略也“无键可删”，evicted_keys 可能只涨一点点，但 used_memory 居高不下，写操作持续失败。此时 keyspace_hits/keyspace_misses 会异常，缓存命中率暴跌——这不是淘汰失效，而是策略选错了范围。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
INFO memory 里哪些字段必须盯住
-
maxmemory：实际生效的上限值（注意单位，可能被配置成字节但显示为 MB） -
mem_fragmentation_ratio：大于 1.5 就要警惕内存碎片，它会让used_memory看似没超限，但实际分配失败 -
mem_allocator：若用的是jemalloc，碎片问题更隐蔽；libc则更容易暴露 -
evicted_keys和expired_keys要一起看：前者是内存淘汰，后者是过期删除，两者叠加才反映真实清理能力
用 redis-cli --stat 实时观察淘汰抖动
这个命令每秒刷新一行统计，重点关注 evicted_keys= 后面的数字跳变。如果它在某几秒内猛增几百上千，说明有批量写入或大 key 写入触发了集中淘汰，这时 latency 很可能同步飙升——因为淘汰是同步阻塞的。别只盯着平均值，瞬时峰值才是压测和线上告警的关键信号。
allkeys-lru 却发现热点商品信息总被清掉，大概率是访问模式不满足 LRU 假设，或者有某个定时任务反复写入冷数据占满空间。这时候看单个 key 的 OBJECT FREQ 和 OBJECT IDLETIME 比全局指标更有诊断价值。 
