要定位被淘汰的key，需监控evicted_keys增量、expired_keys飙升情况，并结合redis 7.0+的memory usage与object freq抽样分析；allkeys-lru不安全，应优先用volatile-lru/lfu；lfu更耗cpu因频次衰减更新；验证key是否频繁淘汰可用pfadd+pfcount埋点统计。
怎么知道当前淘汰策略正在踢掉哪些 key
直接看 INFO keyspace 和 INFO stats 不够，它们只给总量。真正要定位“被踢的是谁”，得开慢日志 + 监控淘汰计数器：evicted_keys 每秒涨多少、expired_keys 是不是同步飙升，能初步判断是 LRU/LFU 误伤了热 key，还是 TTL 集中过期导致被动淘汰。
实操建议：
- 用
redis-cli --stat实时盯evicted_keys增量，配合业务高峰时间比对 - 开启
CONFIG SET notify-keyspace-events "Ex"，监听__keyevent@0__:expired事件（注意：这不包含被淘汰的 key，仅限自然过期） - 如果用的是 Redis 7.0+，可搭配
MEMORY USAGE+OBJECT FREQ抽样查疑似被误踢的 key 频次和内存占用
maxmemory-policy 设成 allkeys-lru 就真安全吗
不安全。allkeys-lru 对所有 key 一视同仁，哪怕你存了一堆带 TTL 的缓存和一堆永不过期的配置项，它也会把后者当普通 key 淘汰。结果就是：配置 key 被踢，服务直接读不到默认值，比缓存穿透还难排查。
常见错误现象：服务重启后偶发空指针或配置丢失，日志里没报错，但 evicted_keys 在缓慢上涨。
实操建议：
- 优先用
volatile-lru或volatile-lfu，只淘汰带 TTL 的 key，保底 key 留在内存里 - 如果必须用 allkeys-xx 类策略，确保所有写入都带合理 TTL，别依赖“永远存在”
- 检查客户端是否误设了超长 TTL（比如 10 年），这种 key 在 LRU 中会卡位很久，挤占真实热 key 空间
LFU 淘汰为什么比 LRU 更吃 CPU
LFU 要维护每个 key 的访问频次计数器，每次读写都要更新，且计数器不是简单 +1，而是带衰减逻辑（防止老热点长期霸榜）。Redis 用的是概率性 LFU，但即便如此，高频 key 的 OBJECT FREQ 更新仍比 LRU 的时间戳更新重得多。
使用场景：适合读多写少、热点相对稳定的场景；不适合短时脉冲流量（比如秒杀），LFU 来不及升温，容易把刚热起来的 key 淘汰掉。
实操建议：
- 压测时对比
used_cpu_sys和used_cpu_user，LFU 下系统态 CPU 明显更高 - 通过
CONFIG GET lfu-log-factor查当前衰减强度，默认 10，调低（如 1）会让频次更敏感，但加重 CPU 负担 - 如果发现
keyspace_hits / (keyspace_hits + keyspace_misses)低于 0.8，说明缓存命中差，LFU 可能已失准，不如切回 LRU
如何验证某个 key 是否正被频繁淘汰
Redis 本身不记录“谁被踢了”，只能靠间接证据。最有效的方式是：在业务侧加一层轻量埋点——每次 set 带 TTL 时，同时用 PFADD 记录 key 名到一个 HyperLogLog，再定时用 PFCOUNT 看去重数量；如果某段时间内 set 次数远大于 PFCOUNT，说明大量 key 写入后很快消失，大概率被淘汰了。
实操建议：
- 不要用
KEYS *扫描，生产环境会阻塞；改用SCAN分批抽样，结合TTL判断存活率 - 监控
mem_fragmentation_ratio，如果长期 > 1.5 且evicted_keys同步上涨，可能是内存碎片 + 淘汰策略共同导致无效驱逐 - 注意
maxmemory-samples默认是 5，太小会导致采样偏差——LFU/LRU 实际决策依据就来自这 5 个随机 key，线上建议调到 10～20
淘汰策略不是设完就完的事，它和你的 key 命名习惯、TTL 设置节奏、读写比例强耦合。最容易被忽略的是：同一个实例混存多种生命周期的数据，却用了统一淘汰策略。
