应重点关注used_memory_rss和mem_fragmentation_ratio：若mem_fragmentation_ratio＞1.5，说明内存碎片严重，即使used_memory未达maxmemory，也可能因无法分配连续内存而提前淘汰；同时需确认maxmemory是否已设置、evicted_keys是否增长及命中率是否下降。
怎么看内存是否真的快满了
别光看 used_memory_human，它只是 Redis 自己统计的“逻辑内存”，可能远低于实际占用。真正要盯的是 used_memory_rss（操作系统看到的物理内存）和它的比值：mem_fragmentation_ratio。如果这个比值 > 1.5，说明内存碎片严重，即使 used_memory 没满，Redis 也可能因无法分配连续内存块而提前触发淘汰。
执行 INFO memory 后重点检查这几项：
-
used_memory和used_memory_rss的差值是否持续扩大 -
mem_fragmentation_ratio是否稳定在 1.0–1.3 之间 -
maxmemory是否已设（默认为 0，即不限制，等于没开淘汰） -
evicted_keys是否在增长（说明淘汰已实际发生）
evicted_keys 增长但命中率暴跌，说明策略选错了
如果 evicted_keys 在涨，同时 keyspace_hits / (keyspace_hits + keyspace_misses) 明显下降（比如从 95% 掉到 70%），大概率是淘汰策略把高频访问的键干掉了。
常见误配场景：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用了
volatile-lru，但大量热数据没设 TTL → 这些键完全不参与淘汰，冷数据又占满内存，最终只能淘汰剩下的少量过期键，效果趋近于noeviction - 用了
allkeys-random，却在电商商品详情缓存这种强热点场景 → 随机删掉正在被高并发读的product:123，直接导致缓存击穿 - 用了
volatile-ttl，但业务里大量临时 token 的 TTL 设得过于均匀（比如全设 3600s）→ 淘汰失去优先级，变成事实上的随机淘汰
怎么验证 LFU/LRU 实际行为是否符合预期
LFU 和 LRU 都是“近似”算法，Redis 不维护全量排序链表，而是靠采样（maxmemory-samples 默认为 5）。采样数太小，容易误判；太大，又增加 CPU 开销。
调优建议：
- 先用
redis-cli --bigkeys扫出大 Key，它们会显著扭曲采样结果 —— 比如一个 50MB 的user:profileHash 占据大量内存，但访问频次低，LRU 可能一直不淘汰它，反而把一堆小而热的cart:*删了 - 对 LFU 策略，观察
OBJECT FREQ key_name返回值（仅限allkeys-lfu或volatile-lfu），确认热键的频率计数确实在上升，冷键在衰减 - 临时把
maxmemory-samples提到 10 或 15，再压测对比evicted_keys和命中率变化 —— 如果改善明显，说明原采样不足；如果没变化，问题可能出在数据分布本身
切换策略时最容易被忽略的副作用
改 maxmemory-policy 是即时生效的，但不同策略的“启动门槛”不同：
-
volatile-*类策略依赖键带 TTL，如果当前 DB 里 90% 的键都没过期时间，那切换成volatile-lfu后，evicted_keys仍为 0，Redis 会卡在写入拒绝状态（等同于noeviction） -
allkeys-lfu在刚启用时，所有键初始 LFU 计数都是 0，前几分钟会像随机策略一样乱删，需要至少 10–15 分钟“热身”才能反映真实访问模式 - 切到
volatile-ttl后，如果恰好有一批键 TTL 同时归零（比如批量刷新的 session），会瞬间触发集中淘汰，QPS 波动剧烈，建议搭配maxmemory-samples调高来平滑压力
真正关键的不是“换哪个策略”，而是换之前先看清 keyspace 里到底有多少键带 TTL、大小分布如何、访问频次是否分层——这些比算法本身更能决定淘汰效果。
