allkeys-lfu对“刚写入的高频Key”无能为力，因新key初始counter=5，访问10次仅升至约10，而老key衰减后仍可能剩30+，无法快速超越；且LFU无法实时感知动态热度变化。
allkeys-lfu 为什么对“刚写入的高频Key”也无能为力
LFU 不是“一访问就高分”，而是靠衰减计数器累积热度。新 key 初始 counter = 5（Redis 6+ 默认），哪怕连续被访问 10 次，counter 也只涨到 10 左右；而一个老 key 若历史 counter 是 50，哪怕最近一周没访问，衰减后仍可能剩 30+。结果就是：新高频 key 在 LFU 排名里根本挤不掉旧冷 key。
更关键的是，MEMORY USAGE 和 OBJECT FREQ 无法同时查——你得先用 SCAN 找出疑似热 key，再逐个执行 MEMORY USAGE + OBJECT FREQ，中间还可能被并发写覆盖。所以“刚写入就高频”这个动态过程，LFU 策略本身看不到、也来不及响应。
volatile-lru / volatile-ttl 会让没设过期时间的热Key完全免疫淘汰？
不会。如果配置的是 volatile-lru 或 volatile-ttl，那所有没设 TTL 的 key（包括你刚写入的热 key）**根本不在候选池里**——它们既不会被主动淘汰，也不会参与任何淘汰计算。但问题来了：内存快满了，Redis 只能从那批“有 TTL 的 key”里删，而它们可能全是低频冷数据。结果就是 used_memory_dataset 持续 > 95% maxmemory，但热 key 安然无恙，冷 key 却反复被删又重建，加剧碎片和延迟。
常见误操作：
- 以为“加了 TTL 就安全”，实际反而把热 key 推进淘汰队列（
volatile-lru下它比老冷 key 更容易被淘汰） - 用
SET key value EX 3600写热 key，却忘了后续EXPIRE调整，导致 TTL 缩短成几秒，触发volatile-ttl优先淘汰 - 业务层缓存逻辑混用
SET和SETEX，部分 key 没带 TTL，部分带了，造成淘汰范围割裂
真正该盯住的三个命令组合
别依赖 redis-cli --bigkeys，它连真实内存都算不准。定位“刚写入就被淘汰”的热 key，必须手动串联三步：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
INFO memory确认used_memory_dataset是否持续 > 85%maxmemory，且mem_fragmentation_ratio> 1.4 - 用
INFO stats查evicted_keys是否每分钟增长 > 100，再结合keyspace_hits/keyspace_misses判断是否缓存击穿引发雪崩式重刷 - 用
SCAN配合MEMORY USAGE+OBJECT FREQ抽样检查：比如SCAN 0 MATCH "user:*" COUNT 100，对每个返回 key 执行MEMORY USAGE和OBJECT FREQ，筛选出MEMORY USAGE > 10000且OBJECT FREQ >= 5的组合
注意：OBJECT FREQ 返回值是 0–255 的近似值，不是精确计数；MEMORY USAGE 包含 Redis 内部编码开销（如 ziplist → hashtable 升级后翻倍），这两者偏差常达 3–5 倍。
为什么监控里 evicted_keys 暴涨，但 slowlog 里找不到大 Key 操作
因为淘汰发生在内存分配前，不是命令执行时。Redis 在每次 SET/HSET 等写入前检查内存，若超限，就立刻触发淘汰流程——这个过程不记入 slowlog，也不走命令队列。你看到的 slowlog 都是“已经成功执行”的命令，而真正导致淘汰的，往往是上一秒的 LPUSH 或 INCR，它们本身很快，但累积内存压力后，下一条普通 GET 都可能触发连锁淘汰。
典型现象：
-
evicted_keys每秒 +500，但 slowlog 最长耗时才 0.8ms - 业务日志显示大量 “cache miss”，而 Redis 日志里只有
Evicting key ...，没有对应的大 key 操作记录 -
INFO stats中expired_keys也在同步上涨，说明过期 key 清理和内存淘汰在并发发生，互相干扰
这时候不能只看单条命令，得拉取 10 秒窗口内的 COMMANDSTATS，重点看 cmdstat_set 和 cmdstat_incr 的调用量突增点，再反向查这些 key 的 MEMORY USAGE 分布。
