allkeys-lru“不准”是因为其近似LRU机制：默认仅随机采样5个key淘汰，热key可能连续未被抽中而遭误删，冷key却因偶然采样被误判为最久未用；调大maxmemory-samples可提升精度但增CPU开销。
没有“更好”，只有“更匹配”——选错策略比不配策略更容易误伤热 key。
allkeys-lru 在生产里为什么经常“看起来不准”
Redis 的 allkeys-lru 不是教科书里的精确 LRU，而是采样+近似：每次淘汰时只随机看 maxmemory-samples 个 key（默认 5），从中挑“最久没访问”的删。这意味着：
- 一个每秒被访问上百次的热 key，如果连续几次采样都没抽到它，就可能被漏掉保护；
- 一个刚写入、还没来得及被访问的冷 key，如果恰好在某次采样里“显得最旧”，就会被误删；
-
maxmemory-samples调太小（比如保持默认 5），在 key 数量大、访问不均匀时，淘汰偏差会明显放大。
典型现象：INFO stats 里 evicted_keys 持续上涨，但 keyspace_hits / (keyspace_hits + keyspace_misses) 却在下降——说明缓存命中率被自己淘汰策略拖累了。
allkeys-lfu 不是“更高级”，而是换了判断维度
allkeys-lfu 看的是频次，不是时间。但它用的是 8 位对数计数器（0~255），不是原始访问次数。关键行为包括：
- 计数器增长概率随当前值升高而降低（
lfu-log-factor控制斜率，默认 10）； - 计数器会衰减（每分钟减 1，由
lfu-decay-time控制，默认 1）； - 新 key 默认从
lfu-init-val（默认 5）开始，不是 0——避免刚写入就被秒删。
所以它适合“长期稳定热点”场景（比如商品详情页、用户基础信息），但对“突发短时热点”（如秒杀开场前 1 秒涌进的临时 key）反应滞后——计数器还没涨起来，内存就满了，照样可能被淘汰。
怎么快速判断该用哪个
别靠猜，看数据特征：
- 如果你的
OBJECT FREQ命中差异极大（比如 top 10 key 的 freq 都 >200，其余大部分 allkeys-lfu 更稳； - 如果你的访问模式是“大量 key 轮流活跃”，且单个 key 生命周期短（比如 session、临时 token），
allkeys-lru更合适； - 如果业务有明确“过期语义”（比如验证码、限时配置），优先考虑
volatile-*系列，而不是allkeys-*； - 切记：
allkeys-lfu必须配合足够大的maxmemory上限——否则 LFU 计数器根本来不及积累，就退化成随机淘汰。
调参比换策略更重要
很多人一遇到淘汰异常就急着换策略，其实先调几个参数更见效：
- 把
maxmemory-samples从 5 改成 10 或 15，allkeys-lru的稳定性会明显提升； - 对
allkeys-lfu，把lfu-log-factor从 10 降到 5，能让低频 key 更快“冒头”，避免被高频 key 长期压制； - 把
lfu-decay-time从 1 改成 10，让历史热度保留更久，适合变化缓慢的业务； - 所有调整后，用
redis-cli --stat观察evicted_keys增速和hit_rate变化，至少盯 15 分钟再下结论。
真正难的不是选 LRU 还是 LFU，而是搞清你系统里 key 的访问分布到底长什么样——计数器不会骗人，但采样会绕过你最关心的那个 key。
