allkeys-lru看最后一次访问时间，allkeys-lfu看带衰减的访问频次；前者对突发访问敏感、适合热点短期集中场景，后者更抗干扰、适合访问均匀稳定场景。
allkeys-lru 和 allkeys-lfu 到底差在哪
核心区别不在“淘汰逻辑”，而在 Redis 如何定义“该淘汰谁”：allkeys-lru 看的是最后一次访问时间，allkeys-lfu 看的是访问频次（带衰减）。Redis 的 LRU 是伪 LRU —— 它不维护完整链表，而是靠 maxmemory-samples 随机采样 N 个 key，挑出 lru 字段最小的那个；LFU 同理，但 lru 字段低 16 位存访问频次，高 8 位存“最近访问时间戳”，频次会随时间衰减。
这意味着：
-
allkeys-lru对突发访问敏感：一个 key 被查一次就“续命”，可能长期驻留，哪怕之后半年没再碰 -
allkeys-lfu更抗干扰：高频 key 确实更稳，但冷数据如果某天被批量扫一次，不会立刻变成“热数据”，因为频次衰减机制会压低它的权重 - 两者都依赖
maxmemory-samples值（默认 5）；设太高（比如 100）会增加淘汰时的 CPU 开销，太低（比如 1）容易误杀
冷热数据区分明显时，优先用 allkeys-lru
典型场景：电商首页商品缓存、用户 feed 流、热点新闻列表。这类业务里，少数 key（如爆款商品 ID、热搜话题）被反复读取，其余大量 key 访问稀疏且集中于短期（比如新上架商品前 2 小时流量高，之后骤降）。
这时候 allkeys-lru 表现更稳：
- 热点 key 每次访问都重置 lru 时间，几乎不会被淘汰
- 冷 key 即使曾被访问过，只要间隔久，lru 值就会变小，自然进入候选集
- 比
allkeys-lfu更少受“偶发扫描”影响——比如后台任务遍历全量用户做统计，不会把所有用户 key 都刷成“高频”
注意：如果业务存在“周期性访问”（例如每小时整点拉一次报表缓存），allkeys-lru 可能误判为持续活跃，此时需结合 TTL 控制生命周期。
访问频率趋近均匀时，allkeys-lfu 更合适
典型场景：SaaS 多租户配置缓存、微服务间通用状态码映射、灰度开关配置。这些 key 的访问没有明显峰值，每个租户/服务调用频次接近，但总量大、个体差异小。
allkeys-lfu 在这种场景下更公平：
- 它不会因某次偶然访问就把一个低频 key “保命”太久
- 频次衰减机制让 key 的热度随时间自然回落，更适合长期稳定的访问分布
- 避免
allkeys-lru在均匀访问下出现“随机驻留”现象（即谁刚被读谁就卡位，淘汰顺序接近随机）
但要注意：allkeys-lfu 的频次统计有精度限制（8 位，最大计到 255），超高频 key（如每秒百次以上）频次会饱和，失去区分度。
volatile-* 类策略基本不用在纯缓存场景
如果你的 Redis 只当缓存用，所有 key 都设了 EXPIRE，看起来 volatile-lru 和 allkeys-lru 效果一样？不是。
真实风险在于：key 的过期时间是业务代码控制的，一旦漏设、错设、或因异常未执行 EXPIRE，那个 key 就永远进不了 volatile 策略的候选集，最终撑爆内存触发 noeviction 或 OOM。而 allkeys-* 策略不依赖 TTL，兜底更可靠。
所以除非你有强约束保证“所有缓存 key 必须带 TTL”，否则别碰 volatile-*。连 volatile-ttl 这种看似“聪明”的策略也慎用——它只看剩余 TTL，不看访问行为，容易把刚写入但还没怎么用的热 key 提前干掉。
真正容易被忽略的点是 maxmemory-samples 的调优。它不像 maxmemory 那样显眼，但直接影响淘汰质量：默认值 5 在小实例（redis-cli --stat 观察淘汰率和命中率变化，再决定是否调到 10～20。
