应先通过INFO stats中evicted_keys是否脉冲式上涨、expired_keys是否同步飙升、total_commands_processed是否下降三指标交叉验证淘汰行为；若evicted_keys为0但延迟仍高，则问题不在淘汰策略本身，可能源于AOF rewrite、RDB fork或LFU计数器衰减重分配。
怎么确认抖动真由淘汰策略触发
别一看到延迟升高就怀疑淘汰策略，先看 INFO stats 里有没有真实淘汰行为。重点盯三个字段：evicted_keys 是否脉冲式上涨（比如每秒突增上千）、expired_keys 是否同步飙升、total_commands_processed 是否明显下降——这三者同时发生，才说明淘汰正在抢主线程资源。
如果 evicted_keys 稳定为 0，但延迟尖峰仍在，问题大概率出在 AOF rewrite、RDB fork 或 LFU 计数器衰减重分配上，不是淘汰策略本身的问题。
volatile-ttl 在短生命周期 key 场景下为什么容易抖动
volatile-ttl 每 100ms 扫描一次 expires 字典，只要大量 key 的剩余 TTL 接近 0（比如批量设了 60s、120s 这类整数过期时间），就会集中触发惰性检查 + 主动驱逐。这个过程阻塞主线程，导致：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
redis-cli --latency显示周期性 20–50ms 延迟尖峰 - 客户端偶发
READONLY You can't write against a read only replica错误（实际是写命令被卡住） -
INFO memory中mem_fragmentation_ratio波动剧烈（频繁内存分配/释放）
allkeys-lfu 替代 volatile-ttl 的实操要点
换策略不是改一行配置就能完事，必须配合业务层调整：
- 把原本带
EXPIRE的 key 改成永不过期，value 里加逻辑过期字段（如{"exp": 1743790260, "data": "..."})） - 配置
maxmemory-policy allkeys-lfu，同时启用lfu-log-factor 10和lfu-decay-time 1，否则高频 key 会永久霸占内存 - 注意：LFU 计数器只在 key 被读取时更新，首次写入后若无访问，不会进入淘汰排序
- 每个 key 多存 16bit 计数器，内存开销比
volatile-lru高约 15%，上线前需压测验证
淘汰策略配错的典型错误现象
只设 maxmemory 但没配 maxmemory-policy，Redis 默认用 noeviction。结果就是：
- 内存打满后所有写命令直接返回
(error) OOM command not allowed when used memory > 'maxmemory' - 业务报错而非平滑淘汰，这不是“抖动”，是服务级中断
- 用
volatile-ttl处理 session 类数据时，TTL 全设成 60s，导致整点过期风暴 - 对带强时效要求的数据（如秒杀 token）误用
allkeys-lfu，冷 key 没被及时清理，反而挤占热数据空间
真正难处理的从来不是策略本身，而是业务语义和淘汰机制之间的错配——比如一个 key 该不该被淘汰，得由业务逻辑判断，而不是靠 Redis 自动猜。
